SED Data Model working draft (on behalf of D. Tody)

[Mark Cresitello-Dittmar]

Doug..
This does look like we're converging.

Comments ensue...

general:
   I still think the term "SED" is being used in two different 
contexts.. when discussing a 'segment' of the SED and for the SED itself.
   This feels kind of like the 'Segment' discussion in Spectral. I'm 
going to introduce a term "UniformSPS" below.

Section 2:
   "no attempt is made at this stage to reconcile the data in the 
different segments"
    One requirement we got for Iris is that the segments of an SED must 
be "compatible" quantities, but not homogenous.  Is this generally true, 
(so that this should be clarified)? or only relevant for certain use-cases?

   "Uniform (or rebinned)"  I think implies a synonym relationship, 
while the description that follows shows that they have a different 
level of processing.  Also, it says that rebinned handles overlaps.  
Does that mean that Uniform does NOT.. so the single Uniform sequence 
can have overlapping data?

Section 3.1/Figure 2:
   I think this maps to Spectral better if you shift it up a level... 
that document already contains a container for a list of BaseSPS 
objects.  Spectral:Section 2, pg 11 - "Spectral" object.
   -----------------------------
    SED = Extension of Spectral
      + Adds UniformSPS
      + UniformSPS is an extension of BaseSPS as described by your SED 
node (without the 0:n Segments)
      This way SED contains a UniformSPS plus a list of BaseSPS, which 
you may want to restrict to Spectrum, PhotometryPoint, TimeSeries as you 
do in Figure 3.

    A Uniform SED = SED with UniformSPS including DATA, and empty list.
    Aggregate SED = SED with UniformSPS with no DATA (or possibly with), 
and list content

    The Uniform SED could be interpreted by Spectral aware software by 
extracting the UniformSPS
   ----------------------------

   Aggregate SED - Bullet points:
     + aggregate composed of actual BaseSPS extensions OR references to 
them..
        - so you want to define a Segment object which contains EITHER a 
URI or an instance of a BaseSPS extension [Spec, PP, TS]
           Segment
              * ref:idRef
              * sequence:BaseSPS[restrict Spec, PP, TS]

          that makes my suggestion above less useful.  However, I'm not 
a fan of defining an extension of a thing which contains that thing.  I 
prefer defining a container for it.  If it isn't Spectral, but an SED 
container which holds a UniformSPS plus list of Segments, that's fine, 
but I'd then vote for removing the "Spectral" object from the Spectral 
model, cuz if we don't use it here.. where will it be?

I see you're trying to make a stronger connection between the SED and 
the UniformSPS than I.  If that is to support the above, recall that the 
UniformSPS allows for Data.TimeAxis and Data.SpatialAxis, which Spectrum 
does not.. it will also need to have a unique Dataset.Type value which 
is not "Spectrum"... so for Spectrum savvy software to use it, they will 
have to either be ignoring the Spectrum requirements or make special 
allowance.  In either case, I'm not sure why SED itself must be a 
BaseSPS extension to allow that.

Section 3.3: Namespace
   This ties in with the xmlns comment on the Spectral model (as you 
note on pg 11)
   This seems at first to be against convention...  I'm trying to see 
how things go across the division.
   If we apply the normal Utype inheritance/extension rules (like we did 
in Spectral for the PhotometryFilter elements)
    (presumably SED is not part of the utypes)
    sed:Dataset
    sed:Dataset.DataModel
    sed:Segment
    sed:Segment.ref
    sed:Segment.Spectrum
    spec:Segment.Spectrum.Dataset.DataModel
spec:Segment.Spectrum.CoordSys.FluxFrame.PhotCal.PhotometryFilter...

   I don't think that is what you mean.  Do you want to specify that 
this model does NOT use the defacto UType extension convention, but 
defines each segment instance as it's own base using that namespace?

    sed:Dataset
    sed:Dataset.DataModel
    sed:Segment
    sed:Segment.ref
    sed:Segment.Spectrum
    spec:Dataset.DataModel
    spec:CoordSys.FluxFrame.PhotCal.PhotometryFilter...

   That doesn't look quite right either, I don't see why that would be 
OK here and not for the Char or Photometry elements of Spectral.
   But this goes heavy into UType land..

Section 3.5.1:
   + Utypes containing SED?  Isn't this contrary to the changes we did 
to remove the 'Spectrum' node from Spectral utypes?
   + these fields provide information which is readily determined from 
the data product, so are you thinking of these as query metadata?
   + isn't this similar to the discussions on Spectral that created the 
DataSet object?  would these items fit under an extension of Dataset?

Section 3.5.2:
   + Defines extension to Spectral:Data for the SED node (what I called 
the UniformSPS above).  thats fine
   + "Any attribute of the SpectralDM may be included as a data column 
in the uniform SED."
      That is a mighty powerful statement.. I think that will need some 
clarification.
      (and makes for a mighty big UType list )


We'll worry about serialization later.