SDM evolution roadmap

[CresitelloDittmar, Mark]

Markus,

I've finally been able to take a look at the new serialization.  I went
through the first table, assuming the rest are structurally identical.

The UTypes and groupings look good for the most part.. a couple notes:
   o looks like the comment regarding the top-node params is resolved (eg:
"spec:Spectrum.Dataset.DataModel" is now "spec:Spectrum.DataModel" )
      ** is a bit hard to manually spot them, amongst the PARAMs, but they
are there.
      ** secondary comment that it'd be easier to read overall if the
PARAMref-s had the UTYPEs, but the PARAMs did not.  But they did help me
find the match!.
   o a few PARAMs with UTypes are not included in their respective GROUP.
      - "spec:Spectrum.Target.Class"
      - "spec:Spectrum.Char.FluxAxis.Ucd"
      - "spec:Spectrum.Curation.Publisher"
      - "spec:Spectrum.Data.SpectralAxis.order"
  o two errors
      - "spec:Spectrum.Target.Redshift" is in Target GROUP, but also in
Derived GROUP.
        These are different (model-wise), and the Derived value would have
UType "spec:Spectrum.Derived.Redshift.Value"
      - "spec:Spectrum.Length" has no value, but the DATA binary stream
definitely contains rows.

Other comments:
  o most of the PARAMs have no value... so while they are there.. they
aren't terribly useful.
  o the added item for 'order' is a PARAM with UTYPE in the "Data" node.
This should be fine.. indicating the value is constant for all rows of the
table.
  o UCD discrepancies (no comment on legality/correctness, just differences
from the spec.)
     - "spec:Spectrum.Curation.PublisherDID":  missing specified UCD
     - "spec:Spectrum.Char.SpatialAxis.Coverage.Bounds.Extent":
spec="instr.fov"  file="phys.angSize;instr.fov"
     - "spec:Spectrum.Char.SpectralAxis.Coverage.Bounds.Extent":
spec="instr.bandwidth"   file="em.wl;instr.bandwidth"
     - "spec:Spectrum.Length": missing UCD
     - "spec:Spectrum.Char.FluxAxis.Accuracy.StatError": UCD is missing a
bit at end. spec has "em.*" which would presumably be "em.wl" in this
dataset but file just has "em"
     - "spec:Spectrum.Char.FluxAxis.Accuracy.SysError":  ditto
     - "spec:Spectrum.Char.FluxAxis.Accuracy.SysError":  ditto
     - "spec:Spectrum.Char.SpectralAxis.Accuracy.StatError":  ditto
     - "spec:Spectrum.Char.SpectralAxis.Accuracy.SysError":  ditto

Mark




On Thu, Aug 18, 2022 at 7:37 AM Markus Demleitner <
msdemlei at ari.uni-heidelberg.de> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://vomx.oats.inaf.it/pipermail/dm/attachments/20230320/6e26db61/attachment.htm>