Re: SED serialization

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:

1. 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).
2. 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 Received on 2007-02-14Z10:49:33