A modest proposal for VOEvent

[Rob Seaman]

Hi,

I've been swamped, just getting back to this.  Am working backwards  
through the mail.

On Feb 23, 2009, at 5:58 AM, Bob Denny wrote:

> Should orbital elements be a WhereWhen and not a What? Elements  
> combined with a
> Time give a Position, thus a WhereWhen? I'm not clear on the *role*  
> of orbital
> elements in a VOEvent message, so maybe I'm off here?

Orbital elements have two roles:

	1) they are familiar from MPC and IAU telegrams.  VOEvent needs to be  
able to capture other transient alert protocols.

	2) They are targeting coordinates for future observations.  This is  
the role of WhereWhen.  Whether they can also be expressed in What  
Params is a separate issue.

> If they are critical, then
> their form(s) should be constrained and not expressed in What (which  
> is after
> all unconstrained).

I tend to agree, but above all else we need consensus.  The Pan-STARRS/ 
MPC partnership has already invested a lot of work in building this  
consensus, let's start with that as a foundation.

> As always, I'd like to see units go away in constrained data. If the  
> orbital
> elements are of some type, then everyone should know not only what the
> parameters that make up that type of elements are, but also that  
> each of the
> parameters always has the same units.

Well, I'd say that constrained data should have constrained units.   
Whether that amounts to a single option is a matter for discussion in  
each case.

> Consider a VOEvent message as a one-to-many thing. Why require the  
> many (the
> receivers) to provide every conceivable/allowable conversion? One  
> conversion
> (maybe) at the sending end (the "one") takes care of it. Everyone  
> knows what
> units to expect for each bit of data. Then the receiver only needs  
> to make
> specific conversions needed internally by its logic and maybe that's  
> no
> conversion at all!

There are now and always will be different flavors of packets.  I  
share your point of view about the ideal, but pragmatically VOEvent  
and the VO have to handle many to many mappings.  The registry is the  
general venue for this, VOEventStreams, the specific battlefield for us.

> In the (unconstrained) What section, though, of course units are  
> needed! And
> Roy, I finally get it with dataType - but probably for a different  
> reason than
> you proposed it :-) A Param needs both units and dataType.
>
> Anyway, to address the validation and expression of What (and yes I  
> am getting
> to dataType!): <What> /can/ be validated as to its structure, and  
> turned into an
> object model. But each Param is a 'blob' with unconstrained  
> properties and no
> value (it's not <param x="a" b="y">value</param>, at least not now).  
> Yet it
> allows unlimited expression. So it's a tradeoff.

Roy addressed the blob issue a few days ago.  I have nothing to add.   
Schemata are indeed about structure.  The simpler we keep both, the  
better.

> What if we used the SCHEMA data types rather than types from VO  
> vocabulary or
> some other set of types? In principle, this would allow a known  
> Param to be
> validated by XML/schema. If the Param is known, a mini-schema could be
> constructed for that Param. Pluck the Param out of the message XML  
> and make a
> separate XML message out of it, referencing the mini-schema. Feed  
> that into the
> XML engine and you have validation because the data type is a schema  
> data type.
> This principle could be applied to entire Groups too. I know it  
> sounds weird...
> but I can see some sort of plug-in architecture for "known" Params  
> and Groups.
> This creates a new vocabulary. Is this ridiculous (it might be!).  
> But it's an
> idea...

Maybe that'll work.

Rob