Registry in RSS
seaman at noao.edu
Thu Jan 14 10:16:40 PST 2010
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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the registry