refocusing the discussion

[Rob Seaman]

Howdy,

Roy has requested that the hammer-and-tongs schema discussion move  
over to a smaller group - I'm sure he'd be glad to add you to that  
group if you feel left out...

In the mean time, I thought I'd outline what I consider to be the  
context out of which the schema schism grew.  Perhaps this will spark  
other discussions that focus more directly on the VOEvent  
specification that is on the table, not on the ideal notion of same.   
We most certainly do appreciate comments such as Tony's that clearly  
indicate an attentive reading of the document.

VOEvent seeks to be responsive both to the historical context of  
astronomical transient alerts as well as the emerging trends that  
suggest that we are approaching an era of an unprecedented scale of  
event reporting.  Facets of the specification appeal to either the  
historical or future context or both.

A VOEvent "packet" (as good a word as any, I still believe) happens  
to be expressed as an XML document for all the usual reasons - but  
XML is a means to an end.  Each packet conveys metadata of a rich  
variety that addresses several needs:  curation, citation,  
characterization and targeting might be one way of dividing this up.   
I won't belabor each of these, and the mapping between these and the  
"who, what, where, when and how" of the specification is only  
approximate.

Let's talk a little about characterization and targeting, however.   
By characterization, I principally mean the rather loose-fitting  
facilities provided by <What> and <Why>.  Whether these are expressed  
using the loathsome, despicable <Params>, or rather via lithe and  
lovely extension schema, this part of the specification focuses on  
providing subscribers with confidence in the publishers' analyses of  
observations - enough confidence to commit real telescopes, real time  
and real money to follow-up those observations.

It is only after characterization that targeting becomes important.   
Some client observatory has decided to make an observation and the  
targeting information (which may, of course, also be used during the  
characterization phase) now has to be used to drive the telescope to  
a precise position on the sky.  As such, the consensus at the VOEvent  
workshop was to use a very tightly fitting, strongly typed facility -  
namely STC - to convey targeting information.  The extension schema  
discussion is only a pale echo of the vigorous give-and-take we had  
over expressing space and time coordinates.  Ultimately, of course,  
targeting information must be acted upon and our most decisive choice  
was simply to leave all such actions in the hands of RTML.  It is  
Rick, perhaps, who will inherit our biggest headaches.

In each case - loose-fitting characterization and tight-fitting  
targeting - I believe we converged on the right solution for this  
problem.  If we were addressing another problem, we might well choose  
the opposite solutions to fit.  VOEvent is a solution to a very  
specific class of problem.  Unlike STC, for instance, VOEvent is not  
intended to provide a general purpose VO facility - although I  
suspect that VOEvent will turn up in some unexpected places and be  
used in some surprising ways.

The question posed is whether there are loopholes in the logic - as  
it exists in v0.94 - or whether the description of said logic  
adequately captures the underlying intent.  We have seen that the  
discussion of identifiers needs clarification before v1.0 is  
released, and we've added extension schema to the list for  
consideration for v1.1, where it joins authentication and VOConcept.   
This will be the choice for other suggestions, as well - whether to  
address the issue now, or rather, later.

Thanks!

Rob Seaman
NOAO