Madrid InterOp roundup

[John Swinbank]

Hi Rob,

On 25 May 2014, at 16:52 , Rob Seaman <seaman at noao.edu> wrote:

> "Strong IVOA notes" sounds a lot like "registered FITS conventions".  Some here (not me) are likely coauthors of the recently submitted "paper I" that (among other things) criticizes this style of standardization.  Thoughts?
> 
> However, I suggest some name other than "strong note" be used.  The essence of a note is that you are bringing some topic to the attention of the community.  On the other hand a recommendation is what IVOA prescribes happen.  "Strongness" is orthogonal to both.

As far as I’m aware, even the name is currently a placeholder: we await a draft version of the standards & processes documentation which will describe the procedure, and can then pitch in with our thoughts. See <http://wiki.ivoa.net/internal/IVOA/InterOpMay2014TCG/2014-05-18_TCG_Minutes.pdf> §4.1 for the proposal to date.

[…]

> Someday this might be a formal process, but in the mean time a strong note supporting SimpleTimeSeries is something like an IVOA-wide agreement not to willy-nilly support other formats.  That is, a little-r recommendation for users to only use STS or alternatives explicitly mentioned in the note.  

I think this is a fair summary: an (existing) note simply expresses the views of the authors, whereas a “strong” note implies that the rest of the IVOA has acquiesced (or, at least, has been consulted).

>> We also discussed the VOEvent Transport Protocol document which I circulated a couple of weeks ago: <http://www.ivoa.net/pipermail/voevent/2014-May/002959.html>. Although the consensus continues to be that moving this towards IVOA standardization is the ultimate goal, Mike had a number of suggestions pertaining to the most recent draft. We agreed, therefore, to open it up to another round of discussion on this mailing list.
> 
> It would help to know what Mike's suggestions were.

I trust that he’ll post them shortly.

[…]

>> Given that both STS and RegExt are now quite mature, we also agreed to start taking steps towards putting them into practice.
> 
> Neither the STS note or your slides indicate how STS might be used by VOEvent brokers or streams.

Indeed. So far as I am aware, this hasn’t been discussed. At least to first order, VOEvent and STS address different use cases: the former as a quick-alert mechanism and request for follow-up, the latter as a convenient format for recording and archiving time-series data. Being able to do both of these things independently is worthwhile.

Of course, as you suggest, accessing & understanding a time series might be fundamental to deciding whether to issue or to react to a VOEvent, and the information contained in a series of VOEvents might be conveniently represented as STS: some cross-over here would certainly be of interest.

> Is the thought to embed STS objects within VOEvent packets, or perhaps as references or explicit citations?  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?

I don’t think (but do correctly me if I’m wrong) that embedding STS within VOEvent would be supported by the current version of VOEvent, and citations are explicitly to other VOEvents. However, referring to STS via a reference in a VOEvent seems reasonable.

>> This involves coordinating with data providers who might wish to publish time-series data
> 
> This implies post facto queries from repositories.  The question for workflows is rather real time delivery.  The original VTP note doesn't dwell on transport of non-VOEvent packets, but is the thought that a VTP stream might interleave VOEvent, STS and other packets?

There’s nothing in VTP which would preclude the delivery of STS messages. However, I’m not sure what that would buy us: low-latency delivery of a lightweight VOEvent which potentially refers to STS (or other) data through a reference seems more generic and more straightforward.

Cheers,

John