Light curves in the IVOA

[Almudena Velasco]

Hi Roy,

We have been working on our OMC light curve service (it has not been 
necessary to change the COROT service) to update it to the last SSAP 
recommendation and to incorporate some of the suggestions you made. In 
particular:

   1.

      Groups don’t contain other groups now.

   2.

      Time is now expressed in “pure” MJD (without a zero point)
      following the Spectrum Data Model recommendation.

   3.

      OMC magnitudes set to 99.0 (“bad” points) have been removed. A
      quality flag column has been added.

Regarding your suggestion of writing an IVOA Note on how to access time 
series, we think it is a good idea. Our experience with OMC and CoRoT as 
well as with other services (e.g., Kepler, WASP, OGLE, AAVSO) says that 
an extension of the SSAP and the Spectrum Data Models would be enough to 
cover most of the cases. In particular, we have identified the following 
issues:

    1- A new utype “Dataset.TimeAxis” is needed in SSAP for native data.

    2-The parameter Dataset.Type should admit a value “TimeSeries”.

    3- A Format= timeseries/fits is needed to distinguish lightcurves 
from spectra

    4- Also, it would be necessary to be able to identify light curve 
services in the registry. To do so, an option is to create a subtype 
“timeseries” of the SSAP in the registry.

Regards,

Almudena



Raul Gutierrez Sanchez escribió:
> Hi Roy,
>
> Sorry for the late reply, I have been on holiday and have just 
> returned now. Let me have a look at your proposals and I will answer 
> you as soon as possible.
>
> I put Almudena Velasco in the loop. She is in charge of the COROT 
> archive.
>
> Regards,
> Raúl
>
> Roy Williams wrote:
>> On 06/16/2010 1:33 AM, Raul Gutierrez Sanchez wrote:
>>  > Hi Roy,
>>  >
>>  > You are right. The TimeSeries part of SSAP is not present in the 
>> current
>>  > standard. It was in previous working drafts and we used them to build
>>  > our services. However, it is mentioned in the current standard as a
>>  > eventual extension of the protocol, and we think it would be the most
>>  > appropriate solution.
>>
>>
>> Raul
>> I would like to start launching and interoperating light curve 
>> services, and what you have done is a most of the work that is 
>> needed, so I am very happy about your real live services!
>>
>> Perhaps we can think about writing a real document about what a light 
>> curve service should look like? That way we can ensure that they real 
>> interoperate. I have a few small questions and concerns about what 
>> you have implemented, and I wonder if I could ask if there could be 
>> slight modifications to your services? Please find attached the two 
>> files (lightcurve-menu.xml and light-curve-instance.xml), where the 
>> first is a listing of links, and the second is a light curve.
>>
>> (1) I see in both of the attached files that you have GROUP 
>> containing GROUP. This recursion in VOTable is something that is 
>> difficult for many parsers and code-binders, and I fought against it 
>> when it was introduced into the VOTable specification. Would it be 
>> possible to just delete GROUPS altogether, since the utype of the 
>> PARAMs already reveals its position in the hierarchy. The GROUPs seem 
>> like a lot of extra complication that adds no information!
>>       <GROUP utype="sed:Segment.Frame">
>>        <GROUP utype="sed:Segment.Frame.Sky">
>>           <PARAM utype="sed:Segment.Frame.Sky.Type" ……./>
>>
>> (2) I see that time is represented by barycentric MJD as in the types 
>> and values below. I am not clear on the meaning of your MJD -- it is 
>> 1300 days from which reference point? But I do not see much of the 
>> STC technology that has been crystallizing in the IVOA with the 
>> efforts of Demleitner (*). Do you think it would be possible to 
>> modify your service to report something more like that?
>>
>> sed:Segment.Frame.Sky.Equinox value="2000.0"
>> sed:Segment.Frame.Time.Type value="MJD"
>> sed:Segment.Frame.Time.RefPos value="BARYCENTRIC"
>> sed:Segment.Coverage.Location.Time.Value value="1305.88"
>> sed:Segment.Coverage.Region.Time.Start value="1305.87"
>> sed:Segment.Coverage.Region.Time.End" value="1305.89"
>>
>> (*) http://www.ivoa.net/Documents/latest/VOTableSTC.html
>>
>>
>> (3) I see that some of your data values have "99.0" for the flux 
>> value, which obviously means missing data. But is there any way in 
>> the SSAP or VOTable specification to say in the metadata "whenever 
>> you see 99.0 it means missing data".
>>
>> Thank you
>> Roy Williams
>>
>


-- 
----------------------------------------------------------------------------- 
Almudena Velasco Trasmonte ( avelasco at cab.inta-csic.es ) 
Lab. de Astrofísica Espacial (www.laeff.cab.inta-csic.es) 
European Space Astronomy Centre (ESAC) 
Villafranca del Castillo - E-28691 Villanueva de la Cañada - Madrid - Spain 
Tel.: 91 813 13 09  Fax.: 34 91 8131160 
-----------------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dal/attachments/20100804/d36bcd7e/attachment-0001.html>