SED serialization

[Miguel Cerviño]

Dear all.

(I have include in the reply the theory list, since some one would be  
also interested in the
discussion, so I also include a brief summary of it)

I am working in synthesis models, which one of the main result are  
the spectra of a stellar
population or, if you want, a set of spectrum generated each one for  
a different
age/evolutionary conditions.

I was began to implement a service with the set of models following  
the "spectral data model"
(c.f.  http://hea-www.harvard.edu/~jcm/vo/docs/spec102/specrc2.pdf)
for each of the models, which I think it is almost fine for this  
pourpose

Now, I would use the "SED data model",
(http://hea-www.harvard.edu/~jcm/vo/docs/spec96/sed96.pdf)
that, If I understood correctly, would allow to provide the complete  
dataset of models.

In the dm list there is now the issue of if SED can be considered as  
a "specialised" case of
spectrum or the opposite (with implications for applications etc...)

 From my point of view, I think that in fact we are dealling with two  
quite different issues:

a) I think that an spectrum dm should be the primary description of  
any spectrum (as all
      agree) It has the advantages from service providers and users  
that you obtain a single
      usable table that can be handle yet by most applications. (In  
this case, SED dm is
      not an especial case of spectrum).

b) About SED data model, I have an alternative perspective:
         I think that it is quite better to make a "general data  
model" that would include not only
        "segments" with collection of spectra/time series, but also  
other possible results that  the
        VO would produce (e.g. arrays that describe the chemical  
evolution of a galaxy where
        each segment has information about different elements, or a  
set of a MonteCarlo
        simulations, and atmosphere library, a set of isochrones or  
evolutionary tracks etc...)

         In this context, I think that the current SED data model can  
be transformed in a more
         general data model that would describe collections of data,  
that also would means that
         produce an VOTable where elements are references to others  
VOTables with the
         specific primary data.

         As possible advantages:
           - It can include a more wide variety of situations (not  
the special one of spectra) without
             increasing the amount of data models. In my case, I  
would provide different model
             results, not  only spectra, without need to include the  
utypes for the particular
             spectrum, the utypes for sets of spectra and different  
utypes for individual models and
             collections for the case of non-spectra/time-series  
results.
          - It would naturally include the issue about how to include  
references to, as an example,
            the description of photometric filters etc...
          - The VOTables that the applications will deal with (and  
also users) will be smaller in
            size and, hence, virtual memory (e.j. my set of high- 
resolution spectra results, that
            I would include in a single VOTable in the SED dm will  
have a size about 4Gb).
          - It allows to "explore" large databases with different  
types of data (e.g. actually, if
            you query VizieR looking for isochrones in Aladin, you  
obtain a sigle VOTable
            with all isocrones, instead the single isochrone you are  
interested in, you can
            obtain this single file from the VizieR server, but not  
with VO applications.
          - It is not necessary that apps that understand spectra  
makes additional implementations
             (the problem SED dm model issue becomes an issue related  
with how to
             query the resgistry)

       The disadvantage I see in this approach are:
            - Modules of the applications that query a service must  
to understand if they obtain a
              VOTable with references to other VOTables of a VOTable  
with data (or a mixing of
              both). Any case, I think that such issue is in someway  
yet included in SSAP protocol (if
              it include the TSAP protocol, i.e. an answer of a query  
ssap?FORMAT=METADATA)
           - Users will need to make more choices before obtain a  
particular result, although will
              depend on the model provider and in if the application  
would make a multiple query
              from the VOTable with the collection.

   Summing up, I think that the it would be better to have a good  
direct access to individual
data (spectrum dm in this case) and that any access to sets of  
"individual data" can be more
easily handle by dm that describe VOTables of VOTables (that can be a  
recurent process)
following a general datamodel instead to provide datamodels for  
specific cases.

It is just a suggestion :)

cheers

	miguel