On the "when" and "where"

Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.de
Wed Mar 23 04:52:47 PST 2005


> What about periodic events?  LSST should be a wonderful machine for  
> discovering variable stars, for example.  One would imagine that the  
> appropriate way to report this would be via a period and zero phase  
> epoch.

Well, last I heard the LSST will cover each area "multiple times per  
month"....  The cosmological use of the LSST is clearly the dominant  
science case (quite rightly - you can't do everything).

>>> If it can't be cut down to about 10 lines of XML for the simplest  
>>> case (including all the angle brackets) I think there is a problem  
>>> here, are there any assumptions made at all if things are left out  
>>> of the XML representation?
>>
>> I'm a little unclear as to the motivation for keeping this so simple.
>
> Ease of implementation and keeping the learning curve as shallow as  
> possible...
>
>> Finally, note that a VOEvent is just a way to transport such  
>> coordinates.  The meaning of the coordinates may be completely opaque  
>> to the VOEvent publisher and subscriber.  Some other code further  
>> upstream from the publisher creates the STC and some other code  
>> further downstream from the subscriber parses it and decides what to  
>> do with the information once it has it.
>
> Possibly, possibly not. I don't see how this would work in practice.
>
> In practice the person "publishing" the VOEvent document will almost  
> certainly be the observing facility, in which case they have to  
> generate it. Anyone consuming the document will want to know where and  
> when the event is, if not, why bother looking at it? Unless you're  
> just archiving it of course, but that's a very specific special case.

After having played with STC time-space-frequency "events" and after  
having thought about how one might put it into other schema (in my  
case, Remote Telescope Markup Language RTML), I've _tentatively_  
concluded:

-  STC must form the "Event" core of any future VOEvent package if  
that's what the IVOA accepts as the basic schema - why bother to repeat  
what has already been done unless there's a better option (which means,  
of course, that it should then replace STC - any volunteers? Time has  
already run out).  The STC <SearchLocation> element certainly covers  
the formal area "when" and "where" for requests as well, albeit not  
within Alasdair's 10 lines of XML.

- There will be lots of servers/clients who want to tap into the VO  
information stream but don't want to have to process the heavy burden  
of STC (there's a price to be paid for formal completeness in the  
description of every possible aspect)

- The multitudes of servers/clients will absolutely LOVE the idea of  
having to write their own individual parsers for what should be  
considered pretty standard uses, even if the IVOA provides standard  
libraries for doing so

- The battles between keeping things simple, useful, and  
reality-checked versus complete and formally useful for all possible  
cases should only be fought on a few fronts - this has definitely been  
the case with RTML, which still doesn't do nearly everything one could  
reasonably want/need but is already getting a bit larger than I'd  
prefer.

Thus

- The simplest means of bridging the gap between the fullness and  
complexity of STC and the down-to-earth needs of users may be for the  
VOEvent community to produce a set of standard filters (e.g. XSLT) for  
standard uses, e.g. STC -> geocentric RA,DEC,UTC for the 99% of users  
who will want to hand STC over to their earthly telescopes.    
Case-based mini-schemas ("schemi"?) which users can then easily plug  
into their own systems
(either local or, e.g., RTML)?

- Maybe all that the VOEvent community then needs in addition are  
scheduling and instrumental interfaces.

In some ways, this means VOEvent is like the Virtual Repository  
community which also wants to tap VO for specific purposes (in this  
case, public outreach).  They also will have to avoid re-inventing the  
VO wheel but will need their own set of interfaces for their own  
purposes.

Just an idea....

Looking forward to many interesting discussions at the meeting in April.

Rick

------------------------------------------------------------------------ 
------------------------
Dr. Frederic V. Hessman      Hessman at Astro.physik.Uni-Goettingen.DE
Universitaets-Sternwarte     Tel.  +49-551-39-5052
Geismarlandstr. 11                Fax +49-551-39-5043
37083 Goettingen                 http://www.uni-sw.gwdg.de/~hessman
------------------------------------------------------------------------ 
-------------------------
MONET: a MOnitoring NEtwork of Telescopes
http://monet.uni-goettingen.de
------------------------------------------------------------------------ 
-------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 4833 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/voevent/attachments/20050323/cdb8cebd/attachment-0001.bin>


More information about the voevent mailing list