Generic FIELD/PARAM metadata items in VOTable

[BONNAREL FRANCOIS]

Dear all,


Le 24/05/2023 à 12:34, F.-X. Pineau a écrit :
> Mark and All,
>
> 2 - On the particular HEALPix example
>
> VOTable represents tabular data, thus a very flat view on data.
>
> I lack fantasy to imagine what to do from an HEALPix number without 
> knowing its order.
> The order is an important piece of data going along with the HEALPix 
> indices.
> When each row have a different order, it is natural to provide the 
> order in a separate column.
> We do not consider the "order" column as a sub-column.
> So, if all rows have the same order, it seems natural to me to provide 
> the info in a PARAM
> (= column of constant value), thus at a table level (and not at a 
> column level).
>
> From my point-of-view, it is the role of GROUPs or VODML or refs
> (or other mechanism possibly complementing but letting the FIELD/PARAM 
> structure unchanged)
> to introduce a hierarchy/logic/semantic(?) (beyond UCDs) in the set of 
> FIELDS/PARAMS.
>
>> You could also end up with multiple PARAMs having the same name, but
>> referring to different columns, but I don't think there is any rule
>> against that.
>
> I probably miss your point since I don't see this as problematic 
> knowing that
> there is (at most) one ref per PARAM and the IDs are supposed to be 
> unique.
> (A good practice, though, should be to have unique FIELDs/PARAMs names).
> Are you thinking of several columns sharing a same PARAM (that will 
> have to be duplicated)?
>
> (I agree for the readability, but are VOTable made to be human readable?
> And from a human point-of-view, the column name (e.g. 'hpx8') and the 
> DESCRIPTION
> of the column should be enough to know the order).
>
> Bonus: when serializing a VOTable in CSV, I tend to think that
> PARAMs should be represented as columns containing constant values
> (so even if the metadata is lost, we still have the PARAMs (redundant) 
> values in output).
>
> What do you think?


I think the PARAM solution works well for the healpix_order issue and 
also for the optional/mandatory issue for service input Parameters

It's really VOTable conservative and requires no change in the schema

I would only suggest to use the utype attribute of this  PARAM to give 
the "healpix_oder" role of the PARAM instead of a name. It's really 
difficult to standardize names at the VOTable spec level and utypes are 
used as ivoa_roles in practice (by the way even when they point to a 
datamodel attribute they serve as ivoa_roles. They could go in a 
specific utype or ivoa_role ivoa list of terms in the future , now taht 
we have MIVOT on the other side )

So following François Xavier example this could give

<PARAM name =hpxo" utype="healpix_order"  value="8" ref="healpix_id"/>
<FIELD ID="healpix_id" name="healpix_id" datatype="int"/>

and for a parameter in a service descriptor

<PARAM name="ID_status_or_whatever" utype="param_optional_tag" 
datatype="boolean" value="false" ref="ID-id" />

<PARAM ID="ID_id" name="ID" datatype="char" arraysize="*" value="" 
ref="id_inthe_table" />

<PARAM name="BAND_status_or_whatever" utype="param_optional_tag" 
datatype="boolean" value="true" ref="band-id" />

<PARAM ID="BAND-id" name="BAND" datatype="double" arraysize="2" value="" 
xtype="interval" />


Of course for Rdf use case, it is a little bit more complicated.

Best regards

François