VOTable 1.5 Working Draft (2023-09-13)

[BONNAREL FRANCOIS]

Hi Tom, all
Le 10/10/2023 à 00:41, Tom Donaldson a écrit :
> Dear Markus and François,
>
> I am following this discussion with interest, but only wish to comment on the suggestion to use GROUPs for this purpose.
>
> In my reading of the GROUP specification, it is too general to be used unambiguously among provider and consumers who have only read the VOTable spec.  GROUPs do supply a very good mechanism for peers to convey mutually agreed upon information, but since that requires mutual understanding of non-public conventions, it cannot be reliably interoperable.  I'd be happy to be proven wrong here, but as Markus points out, without an agreed-upon standard or convention, there is guesswork in both providing and consuming this content.  To me such guesswork is not suitable for interoperability.

Isn't that a general thing in VOTable that the "science aware content" 
is not in the structure of the format but in the attribute values : unit 
for units, ucd for quantities, and utypes for roles ?

If those three attributes have standardized values well defined there is 
no guesswork, I think.

On the other side if we use COOSYS as a GROUP for specific epoch 
propagation purposes, we probably will want some similar behavior for 
TIMESYS tomorrow (Light Curves ?) and also maybe introduce a new PHOTSYS 
element for photometric calibration and photometric system inclusion 
later. This can be end-less.

In addition  if units, ucds and utypes are really not enough and we need 
more sophisticated structure, we now have MIVOT to map standard 
datamodels  onto our VOTables

Cheers

François

>
> .
> .
> .
>     > > That's exactly the discussion I was referring to, this change is a
>     > > transformation of COOSYS into a specialized GROUP. But I can't
>     > > understand why the code would be more complex if you have the
>     > > relationship referenced in a GROUP rather than in a COOSYS playing
>     > > the GROUP's role ?
>     >
>     >
>     > For the writer: You have to manage still another id-ref relationship,
>     > with all the usual uglyness: Come up with an id, make sure it's
>     > document-unique, make sure it stays that way when you merge VOTables,
>     > and so on.
>     >
>     >
>     > For the reader: You have to locate the group(s) that happen to link
>     > COOSYS and the other elements (i.e., tell it from all kinds of other
>     > groups that may be in a VOTable), and then follow the id-ref
>     > relationship to the COOSYS the writer had to worry about in the first
>     > place, handling all the possible errors that may happen (no element
>     > with that ID, the element isn't a COOSYS, etc).
>     >
>     >
>     > Yes, that's not rocket science, but it's not entirely trivial code
>     > either, with many error conditions and corner cases to catch. *If*
>     > we actually improved matters by doing this, I might be willing to
>     > write that code. But at this point I still don't see a practical
>     > problem that introducing this intermediate GROUP would fix. Perhaps
>     > if you tried again to explain the danger you perceive with forward
>     > referencing?
>
> In my reading of the GROUP specification, it is too general to be used unambiguously among providers and consumers who have only read the VOTable spec.  GROUPs do supply a very good mechanism for peers to convey mutually agreed upon information, but since that requires mutual understanding of non-public conventions, it cannot be reliably interoperable.  I'd be happy to be proven wrong here, but as Markus points out, without an agreed-upon standard or convention, there is guesswork in both providing and consuming this content.  To me such guesswork is not suitable for interoperability.
>
> .
> .
> .
>
>
>