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

[Mark Cresitello-Dittmar]

On 10/25/2012 9:27 AM, Douglas Tody wrote:
>
>> a reference to an external dataset OR an actual in-line 
>> serialization.. right?
> I just want to be clear.. you want to allow the Segment to contain EITHER
>
> Yes, this was the intention.  It might be something large, or otherwise
> awkward to copy/include.
>

In that case.. I REALLY liked Omar's idea this afternoon.
   Define BaseSPS extension "SpecRef"
     + 0 Data.*Axis  requirement
     + 0:1 Char.*Axis requirements
     + whatever Char.*Axis Field requirements are deemed useful
     + SpecRef specific attribute  reference of type uri
         (or maybe the Access object?)

With that, the reference and the in-line are BOTH extensions of BaseSPS.
Applications will be able to use them interchangeably.
The referenced file may or may not be VO compliant.

Segment in the diagram then becomes synonymous with BaseSPS.
That basically brings us back to SED being an extension of the 
"Spectral" object of the Spectral model,
adding a UniformSED object which is also a BaseSPS extension.. basically 
the SED model 'SED'
object without the list.


>> I think I'm missing something in the picture then... the Uniform SED 
>> has multiple Segments?
>> From the description, I'm getting:
>>    + Uniform    = Char+Data
>>    + Aggregate = Char+Segment[]
>
> The uniform SED has all the segments from the aggregate SED transformed
> to common spectral/flux units and collected in the Data portion of the
> SED object.  Rebinning to avoid overlaps is optional.  In general there
> can be overlaps due to overlapping spectral coverage of the original
> segments, but since Data represents the spectral coord as a vector this
> can be handled.
>
This is a nice description of the UniformSED view...

>>>> Section 3.5.1:
>>>>  + Utypes containing SED?  Isn't this contrary to the changes we 
>>>> did to remove the 'Spectrum' node from Spectral utypes?
>>>
> Well if necessary we could change the class name of the "complex object"
> to something other than "SED"/ "TimeSeries" / "Image" etc. ("SedProps"
> in your example) and accomplish the same goal.  But I don't see this as
> in conflict with removing the top node name from the Utypes since these
> objects are defined as specific to the class of data and hence not
> sharable.  These really are SED or TimeSeries etc.  specific Utypes.  It
> is not that much different than e.g., Target, which contains only
> Target-specific Utypes.  If we have a Sed.X class for SED-specific
> metadata, but were including a "Sed" prefix in all Utypes (e.g.,
> "Sed.Target.Name"), then applying the same convention we would have
> "Sed.Sed.X" for the Utypes, which is not what is being suggested here.
>
> So the proposal is
>
>   SED object
>     Dataset.X    generic Dataset metadata
>     Sed.X        SED-specific metadata
>     Target.X     Target metadat
>     DataId.X     Dataset identification metadata
>        etc.
>
> But we could instead have SedProps or whatever for the class name if this
> scheme is breaking some rule.
>
In the current iteration SED is at the same level as Spectrum, so the 
same rules
should apply w.r.t. Utypes.  The rule that was imposed upon Spectral for 
the
Spectrum and PhotometryPoint models as I understand it is
"The top level node does not appear in UTypes".

Mark