Madrid InterOp roundup

[Rob Seaman]

Hi John,

> To summarize: we discussed the note endorsing SimpleTimeSeries which Matthew issued on 13 May. It was agreed that this is a useful interim solution until the appropriate IVOA standards for publishing time-series data becoming available [1]. It is not appropriate to put this note through the whole IVOA standardization process. However, the Technical Coordination Group is in the process of drawing up a procedure for “strong notes”, which will be made available to the community in an official RFC process and will carry a weight somewhere between the current notes and the IVOA recommendations. We plan to apply this procedure to the STS note.

"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.

Neither of these proscribes non-conforming community actions.  There simply is no mechanism in the astronomical community for a strong prohibition.  Rather IVOA operates through carrots, not sticks.  What users can do, however, is assert conformance - and conformance can be asserted to versions of either a recommendation or of a note (or of contingent external standards for that matter).

Isn't a "strong note" really a process for IVOA certification of such conformance claims?  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.  Otherwise either a packet conforms to the STS schema or it does not.  Strongness doesn't add anything to conformance per se.

> 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.

> The final document discussed was VOEventRegExt, the latest draft of which Matthew circulated to this list recently: <http://www.ivoa.net/pipermail/voevent/2014-May/002961.html>. This updated version of the previous draft addresses all the comments he had received, and we agreed that this document was now ready to progress to put forward for review as a proposed recommendation [2].

Good!  This is a critical piece in the transient alert workflow.  Without a comprehensive way to discover alert streams and brokers the various time domain use cases will remain stovepiped into manually constructed, non-flexible, overly-specific, hardwired and static workflows.

> 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.  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?

> 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?

Rob