SDM evolution roadmap

[Markus Demleitner]

Hi Mark, hi DM

On Wed, Jul 27, 2022 at 10:54:10AM -0400, CresitelloDittmar, Mark wrote:
> I've added the order and relorder elements/UTypes to the document.
> My understanding of their usage is that you would add one or two FIELDs to
> your table.
>   o utype="spec:Spectrum.Data.SpectralAxis.order"
>   o utype="spec:Spectrum.Data.SpectralAxis.relorder"
> providing the order assignment(s) for each row of the table.

So, I've added a Param with such a utype to each table in the
dataset;
http://dc.zah.uni-heidelberg.de/getproduct/flashheros/data_raw/ca98/blue/n0393.mt
would be an example,
https://dc.zah.uni-heidelberg.de/flashheros/q/echssa/ssap.xml? is an
SSA server that has lots of those.

If you intend to consume Echelle Spectra with this extra metadata,
please let me know if this works for you.

> If you are asking if that example file is 'valid' per the spec, that's a
> bit harder.  I haven't done a thorough review of that file, but from a
> quick-ish scan.

Yeah... We need more validators.  I guess the SDM revision might be
an opportunity to write one for it (no, that's not an offer:-).

> The spec says in Section 8.2:
> 
>    1.
> 
>    We use nested GROUP constructs to delimit data model objects within the
>    main object, and PARAM and FIELD tags for attributes. The nesting beyond a
>    single GROUP is optional, as for cases for which the utypes are unique
>    within a group, the utypes can be used to infer the datamodel structure.
> 
> From this, I gather that there should be a GROUP for each of the included
> nodes in Figure 2, with the exception of Spectrum.
> Per the example, utype="spec:Spectrum" is assigned to the TABLE element.
> So, your example is missing:
>   o The utype on TABLE

Ah yes, that's been a bug.

But:

>   o GROUP utype="spec:Spectrum.Derived"
>   o GROUP utype="spec:Spectrum.CoordSys"
>   o GROUP utype="spec:Spectrum.Data"

I suppose you mean Fig. 5?

Anyway, I've retrofitted these groups; I don't remember why I had
originally deemed them dispensible (then again: does anyone remember
why these groups were introduced in the first place?).

I can't resist noting that the example in section 8 (which
frankly was what I mostly implemented after all these years ago) has
spec:Derived, spec:Data, and spec:CoordSys for these.  If we want
them to be spec:Spectrum.Derived and friends, we should probably fix
the VOTable example for version 1.2, as I suspect most other
implementors will look there, too...

> And at first glance, it looks like it has PARAMs with 'invalid' utypes
> Those with a 'Dataset' node e.g. "spec:Spectrum.Dataset.DataModel"  should
> be  directly on Spectrum ("spec:Spectrum.DataModel")

Ah, the joys of SSA vs. SDM utypes and attempts to automatically
translate between them!

I think that's fine, now, too.  In case you have another few minutes,
I'd appreciate another look at the thing.

Thanks,

              Markus