Madrid InterOp roundup

[Rob Seaman]

On May 25, 2014, at 8:24 AM, Mike Fitzpatrick <fitz at noao.edu> wrote:

>> STS is the response you would get from an existing TimeSeries service e.g. following a GET query for an object.  VTP specifically is for VOEvent docs.  What we don't have is a doc that describes how Brokers and Repositories might exchange mixed data types (e.g. a full event history, ancillary images/STS, etc), that is something the VOEventContainer might address.

On May 26, 2014, at 12:40 AM, Matthew Graham <mjg at cacr.caltech.edu> wrote:

>> On May 25, 2014, at 7:52 AM, Rob Seaman wrote:
>> 
>>> Neither the STS note or your slides indicate how STS might be used by VOEvent brokers or streams.  Is the thought to embed STS objects within VOEvent packets, or perhaps as references or explicit citations? 
> 
> STS is for representing a time series from an archive; it has nothing to do with VOEvent. The issue was to have an interim format for interoperability between light curve providers until Spectral 2.x is out. If you want to put a time series in a VOEvent, use the <TABLE> element that was specifically put into VOEvent 2.0 for that purpose. 


The question had multiple parts and "VOEventContainer" is indeed its closest answer, (though that then opens up the potentially bottomless question of generic IVOA containers).

More parts of that question:

>>> How would such work in practice?  Presumably there would be tools to convert a chronological thread of VOEvent citations into an STS object, or to go back-and-forth from tabular representations either within a VOEvent packet or, for instance, a FITS table expressing a time series?


A reminder that the essence of VOEvent is:

	"VOEvent defines the content and meaning of a standard information packet for representing, transmitting, publishing and archiving information about a transient celestial event, with the implication that timely follow-up is of interest. The objective is to motivate the observation of targets-of-opportunity, to drive robotic telescopes, to trigger archive searches, and to alert the community."  (http://www.ivoa.net/documents/VOEvent/20110711/)

That is, the publication of alerts is for a purpose.

There is no IVOA standard that crosses more boundaries than VOEvent.  Of course STS has something to do with VOEvent - it was created in response to requirements of the VOEvent WG and several of us signed off on it at Hotwired I.  TABLE emerged after heated discussions at Hotwired II.  I, at least, am unsurprised to see STS return to the field of battle.  Having done so, questions like those above assert themselves.

We are finally reaching the point where all the pieces we've been discussing these many years have to be assembled.  The question isn't what one wants to do, but what needs to be done.

Mike continued:

>> Unless it is included as a simple table in the VOEvent doc, subscribers aren't likely expecting an STS.  Rather, a workflow might trigger off a VOEvent notification and then make a separate query to a TimeSeries service to explicitly get an STS.  Of course, we don't have a rec for how to query a TS service either.

And this is why finishing the VOEvent registry work is a key piece (and has been since 2005).  Time domain workflows are themselves subject to rapid changes, and complex interrelated networks of resources may form and reform depending on branch points in the workflow itself.  In particular, a rapid-response workflow itself may well assemble dynamic time series from diverse events and queries.  VOEvent TABLEs will be translated into STS and vice versa.  Presumably the STS note will include advice on discovering STS resources?

Rob