<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">
    <style>
body {
    background: #ffffee;
    color: #000080;
    font-family: Calibri, "Trebuchet MS", Arial, Helvetica, sans-serif;
    font-size: 12pt;
}
pre, tt {
    font-family: "Bitstream Vera Sans Mono", "Lucida Console", "Courier", monaco, monospace;
    font-size: 9pt;
}
</style>
  </head>
  <body>
    <div class="moz-cite-prefix">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 <u>monitor</u>
      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. <br>
      <br>
        -- Bob<br>
      <br>
    </div>
    <blockquote type="cite"
      cite="mid:06c1cc5d-064f-d8d5-736c-f2655a3a6a4f@obspm.fr"
      id="mid_06c1cc5d_064f_d8d5_736c_f2655a3a6a4f_obspm_fr" class="
      cite">
      <pre wrap="">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:
</pre>
      <blockquote type="cite" id="Cite_8870777" class=" cite">
        <pre wrap="">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"
<a class="moz-txt-link-freetext" href="https://gw-astronomy.org/wiki/pub/LV_EM/TechInfo/VOEvent_Documentation.pdf">https://gw-astronomy.org/wiki/pub/LV_EM/TechInfo/VOEvent_Documentation.pdf</a>

This excerpt from the above paper shows how a typed Group is used by LIGO-Virgo to communicate a probabilistic skymap:

&lt;Group type="GW_SKYMAP" name="BAYESTAR"&gt;
   &lt;Param name=" skymap_png_x509 " value=<a class="moz-txt-link-rfc2396E" href="https://gracedb.ligo.org/api/events/G96195/files/skymap.png,0">"https://gracedb.ligo.org/api/events/G96195/files/skymap.png,0"</a> ucd="meta.ref.url"&gt;
     &lt;Description&gt;Sky Map image X509 protected&lt;/ Description&gt;
   &lt;/Param&gt;
   &lt;Param name="skymap_fits_x509" value=<a class="moz-txt-link-rfc2396E" href="https://gracedb.ligo.org/api/events/G96195/files/skymap.fits.gz,0">"https://gracedb.ligo.org/api/events/G96195/files/skymap.fits.gz,0"</a> ucd="meta.ref.url"&gt;
     &lt;Description&gt;Sky Map FITS X509 protected&lt;/Description&gt;
   &lt;/Param&gt;
   &lt;Param name="skymap_png_shib" value=<a class="moz-txt-link-rfc2396E" href="https://gracedb.ligo.org/events/G96195/files/skymap.png,0">"https://gracedb.ligo.org/events/G96195/files/skymap.png,0"</a> ucd="meta.ref.url"&gt;
     &lt;Description&gt;Sky Map image Shibboleth protected&lt;/Description&gt;
   &lt;/Param&gt;
   &lt;Param name="skymap_fits_shib" value=<a class="moz-txt-link-rfc2396E" href="https://gracedb.ligo.org/events/G96195/files/skymap.fits.gz,0">"https://gracedb.ligo.org/events/G96195/files/skymap.fits.gz,0"</a> ucd="meta.ref.url"&gt;
     &lt;Description&gt;Sky Map FITS Shibboleth protected&lt;/Description&gt;
   &lt;/Param&gt;
&lt;/Group&gt;
</pre>
      </blockquote>
      <pre wrap="">
</pre>
    </blockquote>
    <p><br>
    </p>
  </body>
</html>