Subject: re OBJECT keyword

From: Helene Dickel <lanie at astro.uiuc.edu>
Date: Fri, 5 Jun 1998 13:05:05 -0500 (CDT)

To: fitsbits at fits.cv.nrao.edu

Topic: re Draft of FITS standard revision 1.2..
	Section 5.4.2.2 Keywords Describing Observations (OBJECT)
   and	Section 5.2.1   Character String 

As Chair of the IAU Commmission 5 Task Group on Designations, I am  
writing in support of some of the recent suggestions regarding the 
FITS OBJECT key word - its length and its use.

Briefly, the purpose of the IAU Task Group on Designations is to
promote clear and unambiguous identification of astronomical objects 
outside the solar system. Much confusion exists with duplicate acronyms 
and shortened designations appearing in the literature which creates 
problems with archiving and retrieval of data.  Improving the situation 
becomes all the more important as source names are searched in the 
Electronic Journals.  

The Task Group on Designations supports inclusion of Don Well's statement
into Section 5.4.2.2 re OBJECT  and that of Bill Pence into Section 5.2.1 
re Character Strings (both statments attached) in the belief that these 
additions will facilitate rather than hinder the creation and use of 
unambiguous designations which these days can require more than 
24 characters e.g. 

   ("first" release Sloan Digital Sky Survey; Pre-registered to IAU Comm.5)
	1SDSS JHHMMSS.ss+DDMMSS.s  
   <http://vizier.u-strasbg.fr/cgi-bin/Dic?/2887107>

We are also in accord with several other submitted comments which I append.

Thank you for your efforts and best wishes,
Helene R. Dickel, Chair IAU TG on Designations
 
-----------------------------------------------------------
	From Don Wells  <dwells at NRAO.EDU>  April 17 1998 wrote 
	that the text for 5.4.2.2 OBJECT should include the following
	statement (slightly modified by HRD):

"It is recommended that data systems which originate
OBJECT strings (e.g., telescope/instrument data systems) encourage
observers to use strings which conform to the recommendations of the
Designations Task Group of IAU Commission 5 (Astronomical Data) as 
given in "IAU Recommendations for Nomenclature"
<http://cdsweb.u-strasbg.fr/iau-spec.html>."

	Bill Pence <pence at tetra.gsfc.nasa.gov> suggested on May 5 1998
	adding a couple sentences to the end of section 5.2.1 
	(which defines character string keywords) to the effect:

"The maximum allowed length of a keyword string is 68 characters (with
the opening and closing quote characters in columns 11 and 80,
respectively).  Software which reads or writes any character string
keyword should support strings up to this maximum length."

-----------------------------------------------------------------
Other recommendations that the TG on Designation supports are:

	Steve Willner <willner at cfa183.harvard.edu> on May 5 1998
	included the following in regards to allowed "characters"
	in the OBJECT key word strings:

Also, be sure to allow the necessary special characters:  
colons and parentheses at least and preferably slashes and
equal signs as well.

	Arnold Rots arots at xebec.harvard.edu (& William Pence and Nicolaas Kuin)
	wrote on May 11 1998:

I agree that it is absolutely essential that the syntax of OBJECT be
regulated to conform to the Commission 5 guidelines - or at least to
something the name resolvers can be reasonably expected to handle.

For AXAF, we have designated the keyword TITLE to contain the proposal
title, but in principle it could be used for any kind of "junky"
information, like suggested below, at the discretion of the project
that generates the FITS files.

William Pence wrote:
> Nicolaas Kuin wrote:
> 
> >   There is no reason that Keck and Lick could not introduce their own
> > LICK_OBJ for a string like 
> > LICK_OBJ = 'NGC 1234, 400 s, blue filter, 1200 line grating'
> > which then could be put into the header.
> 
> I'd agree that it would be better to invent a new keyword to record the
> user's observation title, (OBSTITLE?) and reserve OBJECT for its
> intended purpose, which is to give the name of the object observed and
> nothing more.

---

From: sla at ucolick.borg (Steve Allen)
Date: 6 Jun 1998 02:02:44 -0700

In article <Pine.GSO.3.95.980605125836.19151C-100000 at dr21.astro.uiuc.edu>,
Helene Dickel  <lanie at astro.uiuc.edu> wrote:
>into Section 5.4.2.2 re OBJECT

Upon much reflection some of us here have come to the conclusion that
the OBJECT keyword should not be forced into this application.

The existing standard has required merely that OBJECT "shall contain a
character string giving the name of the object observed".  This has
led to the development of user interfaces which allow a very broad
interpretation of this keyword.  At this time it is not feasible to
modify the behavior of the user interfaces nor the astronomers such
that the OBJECT keyword can comply with Don Wells' recommendation.

Many FITS files are produced by real-time data acquisition systems at
optical telescopes.  The prescription of the IAU RN is best suited for
archival purposes.  The astronomers who are directing the observations
and setting the value of the OBJECT keyword do not always have
full-fledged IAU designations available before the shutter closes.
Their attention is directed toward validation of the existing data and
most efficient use of the remaining night time, not toward pedantic
filling out of OBJECT names.

Many FITS file browsing utilities, such as IRAF imhead, by default
display the content of the OBJECT keyword when listing the content of
a directory full of files.  This has, unfortunately, led to an
entrenched habit of using the OBJECT keyword as an online notepad to
record other attributes of the observation for easy browsing at the
time of data reduction.

We cannot envision a user interface which can overcome the human
factors involved in the setting of OBJECT values so as to conform
reliably to the IAU Recommendations for Nomenclature (IAU RN).

Instead we recommend the adoption of a new keyword, IAUDESIG, with a
value explicitly specified as conforming to the IAU Recommendations
for Nomenclature.  This may be set by the astronomer at the time
of data reduction, when the nature of the object is better known
and there is no race with impending sunrise.
-- 
Steve Allen          UCO/Lick Observatory       Santa Cruz, CA 95064
sla at ucolick.borg     Voice: +1 408 459 3046     FAX (don't): +1 408 454 9863
WWW: http://www.ucolick.borg/~sla               PGP public keys:  see WWW
Junk mail is irrelevant -- my return address has been assimilated.

---

From: arots at xebec.harvard.edu (Arnold Rots)
Date: Mon, 8 Jun 1998 08:55:25 -0400 (EDT)

Restraining myself from making inflammatory remarks (;-), let me just
comment that while introduction of IAUDESIG might sound like a good
solution to those who have abused the OBJECT keyword in the past, it
also throws a monkeywrench into the designs of those who have
traditionally tried to use OBJECT in the way Don Wells is suggesting.

What I am saying is that the situation is not as simple as Steve
presents it.  He argues that tightening the definition of the existing
keyword causes havoc in one part of the community and hence proposes a
new keyword.  I would argue that the introduction of a new keyword
causes havoc in another part of the community.

Sounds like we need to think this one through a little more carefully...

  - Arnold

> character string giving the name of the object observed".  This has

(Note that the definition says "the name of the object", not "some
name-like description and a grab bag of unrelated items".)

> and there is no race with impending sunrise.

--------------------------------------------------------------------------
Arnold H. Rots                                         AXAF Science Center
Smithsonian Astrophysical Observatory                tel:  +1 617 496 7701
60 Garden Street, MS 81                              fax:  +1 617 495 7356
Cambridge, MA 02138                             arots at head-cfa.harvard.edu
USA                                     http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------

---

From: mjc at star.rl.ac.uk (Malcolm Currie)
Date: 8 Jun 1998 12:13:14 GMT

In article <Pine.GSO.3.95.980605125836.19151C-100000 at dr21.astro.uiuc.edu>, Helene Dickel <lanie at astro.uiuc.edu> writes:
To: fitsbits at fits.cv.nrao.edu

The use of the OBJECT keyword for IAU designations is laudable.
However, I agree with Steve Allen, that in practice it is unlikely to
work because of human nature.  There is also the precedent of OBJECT
being used for other information; this practice is going to be hard
to change.  Remember there are many astronomers still using B1950
co-ordinates and cgs units...

Yes it is frustrating to have a multiplicity of names and
abbreviations when you're searching an archive.  Sometimes it is
merely disorganisation, laziness, or ignorance of the observer;
sometimes it is to maximise the data collected as Steve says; but also
in some cases the obfuscation is deliberate.  To expect that the IAU
designation will be inserted by the astronomer during data reduction
sounds highly optimistic to me, and it's not going to address the
important problem of locating objects from telescope archives.

Adding another keyword may not work in many control systems, where the
data are archived immediately following the observation.  The correct
designation will rarely be entered after archival.  Many archives are
run on a shoestring and I doubt that there are the resources to edit
the headers of most observations.

IMHO the way ahead is education promulgated by the introduction of
observation-preparation tools, such as that of the Gemini Project and
space-based telescopes.  These demand that the targets be specified
_before_ observing commences, for example to avoid duplication.
Support scientists and software designers have a role in ensuring that
the target designations conform to IAU standards.  Astronomers need to
be assured that this is not some bureaucracy, and that it will
actually benefit them and improve telescope efficiency.  The full
designation should not adversely impact on observing efficiency given
graphical user interfaces and schedulers to select the next target.
Indeed preparation before observing has been shown to markedly improve
telescope efficiency.

To summarise:

I'd prefer to use keyword OBJECT, but from a pragmatic view I'd could
live with keyword IAUDESIG.

Let's get the correct designations online prior to observation.

Malcolm Currie
UKATC

---

From: Lucio Chiappetti <lucio at ifctr.mi.cnr.it>
Date: Mon, 8 Jun 1998 16:04:06 +0200

On 8 Jun 1998, Malcolm Currie wrote:

> Helene Dickel <lanie at astro.uiuc.edu> writes:  

> abbreviations when you're searching an archive.  Sometimes it is

  True, but usually one accesses an archive via some name resolver (like
  SIMBAD or NED, which resolve the name to a pair of coordinates and locate
  all objects close to it).

> the headers of most observations.

  human resources or computer/software resources ?  :-(

  A keyword is 68 bytes in an 80-byte card image, thus there is always
  SPARE SPACE to edit it afterwards IN PLACE (no need of rewriting data)
  (e.g. when data go into the archive, when the archive goes public, when
  data are written to a permanent medium like a CD). No problem with h/w
  or s/w. So in principle the observer can use whatever name or nickname,
  and the correct name can be inserted later while archiving. But ...

> _before_ observing commences, for example to avoid duplication.

  I'm quite used to satellite observation scheduling (being essentially
  an X-ray astronomer), but that's not going to solve the problem (one
  proposal PI will always be typing "Mkn501" and another one "1652+398",
  and none place any catalogue designator in front), but often mission
  planning teams are no more staffed than archival teams, so either they
  run a name resolver while checking the proposals, or the problem will
  stay the same.

----------------------------------------------------------------------------
Lucio Chiappetti - IFCTR/CNR - via Bassini 15 - I-20133 Milano (Italy)      
For more info : http://www.ifctr.mi.cnr.it/~lucio/personal.html             
----------------------------------------------------------------------------

---

From: valdes at tucana.tuc.noao.edu (Frank Valdes)
Date: 8 Jun 1998 17:25:52 GMT

I am also in agreement with Steve Allen that the OBJECT keyword has a long
history of use by astronomers and acquisition systems as a human entered
label for the data.  As he noted, this label is also used by many analysis
systems for short, one-line, listings of a collection of data where it
is desired by the observer to get the most information in one line.
Thus including exposure time, filters, coordinates, personal finder
desginations, etc is common practice.

I don't think the original OBJECT keyword was abused but that the original
minimal set of recommend keywords was (appropriately) limited though,
unfortunately, there was nothing defined for an observation label.  So it is
only natural that people used this keyword in preference to the worse
solution of new keywords which other software would not even see.  It is
actually a tribute that many diverse software systems label displays,
graphs, listings, etc reasonably (without great user outcry) using
information in the OBJECT keyword from many diverse sources.

In recognition of this the NOAO FITS keyword dictionary has defined the
OBJECT keyword as the observation label and new keywords for the archival
name following the IAU naming standards.  While it may be some time before NOAO
data taking systems actually make use of this, the proposed names in our
dictionary are OBJNAME/OBJnnnnn (where the latter is when there are
multiple objects in the observation such as with MOS systems).  For an
archive there are also some other things which would be good to define.  In
particular OBJTYPE/OBJTnnnn which give some standard object type such as
star, galaxy, etc.  The dictionary is still a design document which is
quite thorough in trying to define useful information for ground-based
optical astronomical data.

Returning to the question of what happens at the telescope (for the
traditional ground-based scenerio) the acquisition system asks the observer
for a label for the observation.  It is important to minimize how much is
required for the user to enter so a single line is typical.  This
information is added to the data and is generally mapped to the FITS
"standard" in the OBJECT keyword.  This is so entrenched and any changes to
the meaning of OBJECT will not affect past data that I don't think it
should be changed.  What should happen (in new systems) is that the
software systems should take the OBJECT keyword, coordinates, telescope
caches, etc and use name resolvers to automatically create an archival
keyword, such as OBJNAME.  The user could be asked to confirm this which is
an easier requirement during observing than to require a standardized
entry.  Of course, archival ingestion systems can also do this.

I don't think the concern of Arnold Rots is a serious problem.  Any
software can use a precedence and fallback scheme.  The NOAO dictionary
uses this.  An archive system that needs to produce a designation can look
for the more precise keyword, say OBJNAME or IAUDESIG, and if it does
not find it falls back to OBJECT.

There are many ways to address this concern: education, name resolvers, new
FITS standards, queue and proposal entry systems, new systems at new
telescopes, smart archives.  All of these will occur.  But if people are
anxious to do something now that current systems under development might
take into account, then adopting a new keyword is the approach I would
advocate as opposed to trying to change/tighten the original OBJECT keyword
usage.

Frank Valdes
NOAO/IRAF Group

---

From: seaman at noao.edu (Rob Seaman)
Date: 8 Jun 1998 23:19:41 GMT

I agree with the group that argues for a new keyword (or keywords) to
contain an official IAU designation for an object.  The OBJECT keyword
was never defined to contain only official names, and no attempt has
ever been made by large segments of the community to enforce any
particular naming policy.  It seems more than a little late to start now.

However, I also agree that the data acquisition systems should ideally
be responsible for creating the OBJNAME or IAUDESIG keywords (preferably
only one or the other, not both).  Unfortunately, I doubt that I'm the
only one who can comment from experience on the unlikelihood of this
happening for legacy instrumentation.

Note that not all observations are associated with a particular IAU
designated object.  Does the Hubble Deep Field have an official name?
The DSS fields will have no IAUDESIG, for instance.  It would be
impossible to assign a OBJNAME to a "serendipity mode" observation
at some random telescope pointing.  What about names for individual
exposures from whole-sky or other telescope surveys?  The precise
intent of a survey is to provide fodder for only later generating
names, after all.

Note also that the IAU may not be the sole body that we need to consider
as being responsible for granting names.  Do we need to reserve other
xxxDESIG keywords?  (Might I suggest that a shorter abbreviation be
found for "designation" so that more than three characters remain for
the naming organization acronym?)  Alternately, is OBJNAME appropriate
for other than official IAU nomenclature?  Without reserving multiple
keywords to allow keeping multiple namespaces separate, a single keyword
may not be able to resolve naming conflicts.  Is an ambiguous official
name better than an unambiguous ad hoc name?

I'm also leary of relying entirely on positional identifications for
resolving names.  In crowded fields it is quite possible for the
boresight of the telescope to lie nearer to a happenstance object than
to the intended object.  On the other hand, an observation of, say,
halo objects of a nearby galaxy may result in a telescope pointing
that is far from the official center of the galaxy...while narrow
band observations of distant objects may use red shifted filters such
that otherwise centered foreground objects aren't really present in
the field of view in any appropriate scientific sense.  (I'm sure
others can come up with even more convincing examples.)

In general, assigning a single object name (an official IAU name or
otherwise) to each observation of a particular field-of-view relies
intrinsically on the intent of the observer.  And searching an archive
for all observations of NGC1234 (or is that ngc-1234?) is only one
desirable type of database query.

What about observations containing multiple objects?  What about
observations of specific regions of larger objects?  I may want to
search not only for observations of Jupiter, but specifically for
observations of the Jovian Great Red Spot.  Is our software to be
responsible for determining not only whether the GRS is in the
field-of-view, but also whether it is on the proper side of the
planet?  I presume the IAU has a lot to say about languages - but
does FITS have any specific requirements about the language used
to specify a name?  Abbreviations?  Is case significant?  ...

The nature of the problem has not been sufficiently well defined yet.
We shouldn't hurry to a solution until it is.

Rob Seaman
-- 
seaman at noao.edu, http://iraf.noao.edu/~seaman
NOAO, 950 N Cherry Ave, Tucson AZ 85719, 520-318-8248
PGP: 98 8D 8B 49 74 9A 41 88  3A 43 87 54 51 BF 30 4B