Registry in RSS

[Rob Seaman]

On Jan 14, 2010, at 9:03 AM, Dick Shaw wrote:

> Without disagreeing with the fine ideas offered in this thread, I  
> think there may be some value in keeping the conceptual basis and  
> purpose of VOEvent relatively uncluttered.

Indeed.  For a VOEvent mission statement, we have often referenced  
this phrasing from the spec: "VOEvent is a mechanism for broadcasting  
discoveries that others may wish to follow-up, and this purpose  
defines its scope."

The next sentence discusses astronomical discoveries, but I  
intentionally omitted the adjective from the sentence above.  Follow- 
up - of whatever sort - is the soul of VOEvent - we're interested in  
publishing living data that has implications in the real world.   
Hence, for instance, the subtitle of the Hotwired book the WG is  
currently working on:  "The Era of Real-time Astronomy".  These are  
not static, write-only data.

> The example notification from IERS is, in its content, really about  
> a non-event (no adjustment to the time reference system is expected  
> to happen at the end of June).

The twice yearly opportunity to issue a leap second is an event.  Each  
occasion has three values: -1, 0, +1.  Leap seconds are cumulative -  
some repository must keep track of them.  The current notification  
mechanism (prose email) is poorly suited to the purpose of systems  
that actually need to use UTC, and thus must implement leap seconds.   
The IERS mission is itself strongly tied to the same question of  
follow-up.

> A notice about the availability of a new VO resource, while  
> interesting, isn't exactly an event in an astronomical sense. Are  
> these notifications really what VOEvent about? At first blush I  
> would have thought them more appropriate to a news feed.

There are four messaging issues here.  Two have been previously  
discussed, 1) semantic representation, and 2) transport protocols.   
They were discussed because they are appropriate to the mission of  
IVOA to develop such standards.  Two additional issues are the wide  
deployment and reliable operation of 3) actual, and 4) virtual  
communications channels layered on the semantic and transport standards.

The various partners of VOEventNet (such as SkyAlert, eSTAR, VO-GCN,  
etc) are in the business of providing physical communications  
channels.  Presumably oversight of these is a role for the various  
national VO entities who provide the virtual (but not therefore less  
real) brick-and-mortar facilities.  We hope to raise this issue in the  
VAO facility, for instance.

But I took Mike's heretical notions to refer to the fourth  
ingredient.  In VOEvent, the question of virtual channels is addressed  
via creating separate streams of messages.  This would naturally serve  
to separate GRB and SN1e alerts from alerts about non-celestial VO  
resources or timekeeping standards.

Whether this is a good idea is a different question, but there is  
absolutely nothing in the VOEvent standard to restrain usage such as  
Mike mentioned.  That being the case, what value is added by pursuing  
a separate, but extremely similar, range of semantic and transport  
protocols for each new VO use case?  The VOEvent WG has pursued the  
creation of its own semantic and transport protocols - rather than use  
COTS technology, for instance - for various good reasons.  Projects  
that are within some neighboring horizon of VOEvent will face similar  
requirements and can benefit from similar solutions.

Whether these would be deployed on VOEventNet using VOEventStreams is  
a question for the operators of those facilities to address by  
considering the orthogonal issue of what value - to them and their  
users - is added by doing so. Perhaps a particular VO notification  
service would be deployed on project specific servers and define task  
specific virtual channels - but use the same semantic and transport  
technology stack.

Rob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/registry/attachments/20100114/c274b69f/attachment-0007.html>