A modest proposal for VOEvent

[Roy Williams]

Bob

Your message uses the word "unconstrained" three times. But the next 
version of VOEvent will have the "Stream" mechanism to define each 
Param. The stream provides a strong scientific description from the 
makers of the event (eg "5-second running average of flux counts"). The 
Stream definition defines units, dataType, UCD, etc, for each Param.

The nature of the Params is defined in advance, in the Stream record, 
and then the actual event in the middle of the night supplies the value 
of the Param. Collections of Params can represent complex quantities (eg 
flux and 2 types of error).

Params are NOT "blobs" in the stream model: they are precisely defined 
scientific data measurements.

Roy



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? If they are critical, then
> their form(s) should be constrained and not expressed in What (which is after
> all unconstrained).
>
> 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.
>
> 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!
>
> 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.
>
> 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...
>
>   -- Bob
>
>   

-- 

California Institute of Technology
626 395 3670