VOEvent Update

[Robert B. Denny]

This has become too complex and open ended for my little pro/am transient
astronomy project involving ASASSN, NASA. and hopefully soon AAVSO as input. So
I'll _monitor_ this going forward and when it has become solidified, I'll look
at it again. I will say that our goals are to hint at the kind of follow up data
that is needed (phasing, cadence, and color bands or spectroscopic, and also one
or more speckle interferometry facilities).  ALso we're going with "more data is
better" so  not trying to coordinate a single follow-up. If the
requester/alerter gets "duplicate" follow-up data so much the better. They can
take the best.

  -- Bob

> Hi Roy
>
> My first idea was to 're link' VOEvent2 to STC as it was done in the 
> previous version. So it make it not compatible with previous VOEvent2 
> already published. Then discussing with Dave Morris I have changed my 
> mind and try a new schema (let say 2.1) that change list of items to 
> open field and add in complex types other fields with a cardinality 0 to 
> 1 or 0 to N
> Then it can fulfill our request and still validate previous VOEvent.
> My idea was if the concept is accepted to propose a schema (early draft) 
> for modification and extensions. And LIGO-Virgo, CTA, and if they want 
> join Fermi would be good candidate for evolutions of the schema. Swom 
> also because it come from satellite and the question of observatory 
> position and also observation position may be a problem in actual version.
>
> Regards
> Pierre
>
> On 19/10/2017 12:01, Roy Williams wrote:
>> Hi Pierre and Tim
>>
>> I understand that you would like to represent the orbit/ephemeris of *moving* objects as part of the VOEvent packet. Rather than working the way VOEvent was designed -- with typed Groups of Params and Tables -- you propose to build an XML schema extension for this purpose, using all or part of the STC schema. This would then be linked in somehow -- in a way that we found really too difficult in the past.
>>
>> My worry is that parsers that have been built to read "off-the-shelf" VOEvent 2.0 would not be able to parse this enhanced version of VOEvent, and thus we would fail in our mission of interoperability. Another problem would happen when other groups are required to build their own extension schemas for their purposes, and are turned away, first by the technical task, and then by the requirement to have IVOA approval for the extension.
>>
>> Perhaps you can help me understand how the LIGO-Virgo VOEvents would be built using extension schemas? See below. Neither the existing WhereWhen schema, nor the STC schema shows how to represent a *probability density* on the sky, which is the LIGO-Virgo statement of where to find the source. How should this be recast in your suggested mechanism of schema extension?
>>
>> Roy
>> -----------------------
>>
>> LIGO document
>> "VOEvent Documentation: How to read and interpret a VOEvent"
>> https://gw-astronomy.org/wiki/pub/LV_EM/TechInfo/VOEvent_Documentation.pdf
>>
>> This excerpt from the above paper shows how a typed Group is used by LIGO-Virgo to communicate a probabilistic skymap:
>>
>> <Group type="GW_SKYMAP" name="BAYESTAR">
>>    <Param name=" skymap_png_x509 " value="https://gracedb.ligo.org/api/events/G96195/files/skymap.png,0" ucd="meta.ref.url">
>>      <Description>Sky Map image X509 protected</ Description>
>>    </Param>
>>    <Param name="skymap_fits_x509" value="https://gracedb.ligo.org/api/events/G96195/files/skymap.fits.gz,0" ucd="meta.ref.url">
>>      <Description>Sky Map FITS X509 protected</Description>
>>    </Param>
>>    <Param name="skymap_png_shib" value="https://gracedb.ligo.org/events/G96195/files/skymap.png,0" ucd="meta.ref.url">
>>      <Description>Sky Map image Shibboleth protected</Description>
>>    </Param>
>>    <Param name="skymap_fits_shib" value="https://gracedb.ligo.org/events/G96195/files/skymap.fits.gz,0" ucd="meta.ref.url">
>>      <Description>Sky Map FITS Shibboleth protected</Description>
>>    </Param>
>> </Group>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/voevent/attachments/20171019/71a5ffe0/attachment.html>