[iaufwg] [fitsbits] Start of the ''MBFITS" Public Comment Period

[Robert Hanisch]

This topic came up in recent VO discussions, with the idea of using the VO
registry to identify types of FITS files (e.g., this is an HST ACS image,
version 7.2.1, and the keyword dictionary is located here [URL]).  In
addition, each and every FITS file would include an IVOA Identifier that
would point to its external definition.  All well and good, except that
Arnold Rots pointed out that we have some millions of FITS files in
existence that would not have these pointers.

It is fine for the community to know about FITS usage and keyword
definitions.  Do please have a look at the the HST convention(s), if you
want to call them that, at http://www.dpt.stsci.edu/keyword/.  The
documentation is extensive and complex.  I would not expect the FITS
community, or this committee, to review this documentation and approve or
endorse it, even on the stated criteria of completeness, conciseness, and
accuracy.

I guess my point is, fine, let's just put all these documents and links in
the FITS registry and be done with it, especially for the things that are
very instrument-specific.  I would put multi-beam FITS, single dish FITS,
interferometry FITS, and so on in this category.  It's great that the
practitioners in these sub-fields of astronomy have gotten together and
agreed upon keywords and structures.  To me, though, these are not
conventions in the sense of generic schemes for encoding information (like
tiled image compression, foreign file encapsulation, or the INHERIT stuff),
all of which are independent of the type of instrumentation used to acquire
the data.

Bob


On 5/25/07 2:47 PM, "William Pence" <pence at milkyway.gsfc.nasa.gov> wrote:

> Robert Hanisch wrote:
>> On 5/21/07 10:17 AM, "LC's NoSpam Newsreading account"
>> <nospam at mi.iasf.cnr.it> wrote:
>> 
>>> I had a quick glance to the the summary and full specification pdf docs
>>> (quicker for the second).
>>> 
>>> My impressions are :
>>> 
>>>  - the summary is too much a summary for the registry
>>>  - the full specification instead is too detailed for the registry
>>>    (however could be provided as supplementary document)
>> 
>> I agree with Lucio.  In addition, I don't really feel qualified to critique
>> such a detailed and specialized specification.  If it works for this
>> facility, then fine.
>> 
>> This seems less of a convention and more of a keyword dictionary for this
>> particular telescope/application.
> 
> [Note that this is addressed to the IAUFWG email list, not FITSBITS]
> 
> We seem to keep coming back to the question of "what is a convention?",
> and the purpose of the Registry (a similar discussion took place
> regarding the FOREIGN extension convention).  Here is what the Registry
> web page says:
> 
> "A FITS convention is defined as a set of related FITS header keywords,
> and optionally, other data structures within FITS tables or FITS images,
> that are to be used for a specific purpose. Because it is often
> inappropriate or impractical to document these conventions in the FITS
> Standard itself, the Registry provides an alternative process for
> documenting conventions for the benefit of future FITS users."
> 
> There are only 3 requirements for including a convention in the Registry
> 
> 1.  it conforms to the FITS standard
> 2.  the convention is in actual use
> 3.  the documentation is clear, and concisely defines how the convention
> should be used.
> 
> I think this MBFITS convention meets all these requirements.  Some might
> argue that a 60 page description document is not really "concise", but
> we have to be realistic about what documentation we can expect to
> receive; we can't expect people to spend time writing  (and maintaining
> in the future) new documentation simply for the FITS Registry if
> existing documents will suffice.  This is especially true for
> configuration controlled documents like this MBFITS document;  even if
> someone was willing to take the time to write a more concise summary of
> the MBFITS convention, getting approval to release such a document might
> require a lot of time and effort that the project is unwilling to fund.
> 
> There are several other conventions in the queue to be considered for
> the Registry in the near future that are somewhat similar to the MBFITS
> convention (e.g., Single Disk FITS, Interferometry Data Interchange
> FITS, and the Optical/IR Interferometry Data Standard format).   All
> these conventions are fairly complex and have relatively long
> description documents.  I can't think of any good reason to exclude
> conventions like this from the registry, and on the contrary,  I think
> it will prove to be beneficial to the FITS community to have all these
> conventions documented in one place in the Registry.
> 
> Generally speaking, I believe that a "Big Tent" philosophy of allowing
> practically any FITS usage to be documented in the Registry will be
> better for the FITS community, rather than trying to set up narrow (and
> somewhat arbitrary) definitions of what types of conventions are good
> enough to go into the registry.  Once a significant number of
> conventions have been entered in the Registry, then perhaps we can
> consider defining finer sub-categories of conventions.
> 
> Bill