<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
span.EmailStyle19
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;
        mso-ligatures:none;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">Putting keyword-like metadata in a bintable extension(s) is already perfectly legal FITS. Omitting all but the strictly required structural FITS keywords from the primary and extension headers is already perfectly legal FITS.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Proposing a new FITS convention that describes an enhanced FITS data model that does both of these would not invalidate any previous FITS objects or their data model(s).<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">And indeed, such a project would naturally include tools to map classic headers to and from the new tabular metadata format. Mapping from classic to tabular headers could be entirely backward compatible. Using new features enabled by RDB-like
 tabular concepts would not, but this is not required.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Rob<o:p></o:p></p>
<div style="mso-element:para-border-div;border:none;border-bottom:solid windowtext 1.0pt;padding:0in 0in 1.0pt 0in">
<p class="MsoNormal" style="border:none;padding:0in"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="margin-left:.5in">On 8/4/23, 8:31 AM, "Mohammad Akhlaghi" wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="margin-left:.5in">Hi Marjolein,<br>
<br>
> I think that a discussion towards supporting a more elaborate complete <br>
> modern data model is more useful than a discussion if and how to <br>
> shoehorn this in one or more header keywords.<br>
<br>
"Modern" is a relative term: what we define as "modern" today will be <br>
"classic"/"ancient" in 10/50 years!<br>
<br>
Being able to use +30 year old data today, and guaranteeing this for the <br>
next generation in +30 years, is a major asset we have in astronomy <br>
(thanks to FITS!); allowing us to build upon previous work; not <br>
re-starting from scratch.<br>
<br>
We shouldn't (and cannot afford to!) fall in the trap of defining a <br>
different data format every decade!<br>
<br>
Cheers,<br>
Mohammad<br>
<br>
----<br>
Mohammad Akhlaghi<br>
Lead of J-PAS and ARRAKIHS data reduction pipelines<br>
<br>
Centro de Estudios de Física del Cosmos de Aragón (CEFCA),<br>
Teruel, Spain<o:p></o:p></p>
</div>
</div>
</body>
</html>