[task #15912] VOTable input-output

[Mohammad Akhlaghi]

Follow-up Comment #2, task #15912 (project gnuastro):

Thanks a lot for the great feedback François. Indeed, I really look forward
to expanding the elements within 'gal_data_t' to preserve the rich metadata of
VOTable. Hopefully as we start implementing VOTable, we'll see what is
necessary at each level and implement it.

Here are some brainstorms on each point that just occurred to me and I am
adding here only for the record (may be useful later!). We should discuss them
each in separate tasks during the implementation phase of VOTable (tasks that
spin-off from this one).

* A semantic element like IVOA's Unified Content Descriptors
<https://ivoa.net/documents/cover/UCD-20050812.html> (UCD) is indeed a great
point! We can define headers to associate MACROs for each of them. And even
define it as a two-element integer array ('int semantics[2]'): the first
element will have the macro of the standard (for example UCD or UCD1+
<https://ivoa.net/documents/UCD1+/20200212/index.html> in IVOA, but also allow
adding other semantic standards in the future), and the second can be the
macro for the the semantic type of that particular dataset.

* About the grouping of columns, it is very good to think about a good way to
implement it. I also loved this feature when I read the VOTable standard and
already envision so many usage examples of it (in the 'asttable' or
'astmkcatalog' programs). Regarding its implementation, we may be able to
define higher-level structures and not necessarily need to touch the low-level
'gal_data_t'). But we'll have to go into practice and see it it evolves ;-).

* Linking columns (to extract the data from a URI when they are actually
necessary) is also a very good feature to implement! We can use all the good
new functions that you are currently adding to the library for that, thanks a
lot for them ;-).

* Adding parameters for columns is also interesting to consider. Currently for
FITS files (where "keywords" play the role of VOTable's "parameters"), we only
read the necessary keywords as input and each program writes its own new
keywords in the output. I like how CFITSIO deals with keywords: you can
read/write/delete/update them independent of the data in a FITS file. So on
first thought, probably we don't need high-level parameters in the low-level
'gal_data_t': we can add functions to read/write/delete/update certain
parameters from the VOTable based on the program that wants to use the input
data, and write its own output data. But again, this is just my first thoughts
now, let's get our hands dirty and see how it evolves in practice ;-).

Adding VOTable features in Gnuastro will be a very productive step forward, it
is an honor to do it with your help and guidance as the author of the standard
:-). Thank you François.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/task/?15912>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/