An STC "when" and "where" example

[Frederic V. Hessman]

>> Time isn't necessary under all circumstances.

Though it's hard to imagine a VO "event" not having some time reference,
I confess it would be reasonable from a VOEvent point of view to say  
"Something
has happen: don't ask me when it was, just go look at it!".  Thus, no  
time default
should be needed.

>> Wavelength isn't necessary under many circumstances.

My first reaction was to disagree, but the case above can just as  
easily be used
for wavelength/frequency.  No wavelength default needed.

>> [observer's location] Not necessary in many circumstances.

This is the only good case where an astronomical default - "way far  
away" - is
good enough to justify simple RA,Dec,Equinox.

>> Errors are always helpful, but not necessary in all cases.

A default of order arcseconds is admittedly biased towards optical  
ground-based
observations, but not unreasonable. Practically, though, I'd say no  
error default is
absolutely necessary given typical fields-of-view.  If VOEvent clients  
don't like not
having errors (e.g. VLA/VLBI), they can simply pass and wait for an  
event which does.

> And one imagines spatial coordinates aren't necessary under all  
> circumstances :-)

IR observations of the Leonids in Siberia, anyone?

> Again, STC appears to allow making each of these optional.  More to the
> point, this is an opportunity for VOEvent to inform the STC  
> specification.

A very good point: I'm sure Arnold would appreciate some constructive
suggestions on how one could make STC more accessible/useful.  For  
instance,
one should think twice about using data structures which require the  
full set of
coordinate-time-wavelength-observatory info for all the perfectly good  
reasons
above.  Fortunately, I believe that stc:obsDataLocationType requires  
that there be
stc:observatoryLocationType and stc:observationLocationType data, but  
doesn't
require that they be non-empty (both are of type stc:coordSysType which  
is a
sequence of minOccurs="0" elements, which means that no entries should  
be
perfectly acceptable): if this is indeed true, then one should be able  
to generate
and process bare-bones STC info, leaving it up to the customer to  
decide how
much info is really needed/wanted.  Sort of a Darwinian (or maybe Adam  
Smithian)
approach.

> On the other hand, Alasdair is suggesting (I believe) that multiple  
> software
> clients, perhaps written in multiple languages, might require  
> differing levels
> of support for the VOEvent standard itself for various purposes.

Isn't this the whole point of VOEvent, especially given that we're  
bound to accept STC
whether one likes it or not?  We have to allow the whole range of event
descriptions from exacerbatingly primitive  
"don't-worry-just-go-take-a-look" telegrams to
very complex reports, because each of us is going to want to deal with  
a wide range
- though admittedly our own wide range - of possible VOEvent documents.

> It should be an interesting workshop...

Indeed!

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