VOEvent session

[Frederic V. Hessman]

While this discourse is reasonably entertaining, I keep forgetting the  
point.....

Here are some theses I'd like to tack onto your virtual church doors:

* XML is here and probably to stay and there's nothing reasonably  
useful to replace it (yet).
* Controlled content is better than uncontrolled content (e.g. FITS,  
despite all of it's problems, has made our lives much simpler), since  
that's the only way the VO can function.
* The only reasonable way to control XML content (currently) is a  
schema (even if we'd like to have better ways of defining schemata).
* Uncontrolled utypes are just a way of documenting how uncontrolled  
one's content is.
* There are IVOA standard ways to control one's content (UCD, SKOS).
* VOTable is here to stay, whether you like it or not (correllary: You  
will have to be able to process VOTables in a VO context, whether you  
like it or not).

Given these theses, the course would appear to be straightforward...

Rick
		
On 16 Dec 2010, at 07:49, Rob Seaman wrote:

> So consider Roy's example:
>
>> My favorite data model is the complex number,
>
> (I was under the impression your favorite was "the banana".)
>
>> with a data model of Real and Imaginary components. Here are some  
>> representations of the number z=1+2i. The advantage of (1) is  
>> automated code binding and document validation. The advantage of  
>> (2) is flexibility and encoding validity in a non-XML layer. The  
>> advantage of (3) is simplicity and conciseness.
>>
>> (1) "Pure" XML
>> <complex name="z">
>> <real>1</real>
>> <imag>2</imag>
>> </complex>
>>
>> (2) Impure XML a la VOTable, VOEvent
>> <Group name="z" type="complex">
>> <Param name="zr" utype="complex.real" value="1"/>
>> <Param name="zi" utype="complex.imag" value="2"/>
>> </Group>
>
> These are isomorphic as written - not surprising since they are both  
> XML.  What Schema adds to XML is a way to require a certain internal  
> structure.  #1 can require (as a complex number does) that both  
> <real> and <imag> be present.  In the case of #2 a <Group> may  
> require zero, one, or more <Params>, but can't specify that both  
> these utypes must be represented.  XML is not the same as "XML  
> Schema".  These are both pure XML.
>
>> (3) JSON
>> {"z": {"zr":1}, {"zi":2}}
>
> If we were in a position at this late date to consider non-XML  
> representations, we might be well advised to evaluate many other  
> possible options in addition.  It seems clear that IVOA is moving  
> away from what Doug calls "complex XML with schema verification".   
> My question, I guess, is whether IVOA deprecates "complex XML" or  
> rather "schema verification" or rather the combination.
>
> If the argument is that VOEvent should anticipate IVOA trends - and  
> that the trend is to move to a simple baseline schema-verified  
> flavor of XML - and further that complexity is brought back in  
> through a few hundred utypes mapping to a few dozen data models -  
> well, then, it isn't clear what value the schema is at all.  Also,  
> this seems to suggest that all IVOA XML will eventually devolve to  
> VOTables or some other common container for utypes.  (Me?  I'm  
> thinking all snarks are boojums and all VOTables may turn out to be  
> FITS bintables.)
>
> For one thing, doesn't this mean that the STC schema will itself  
> turn into the equivalent of a group of params with utypes such that  
> as Doug says, "the [STC] data model itself...has to be  
> understood...either by human or by code"?
>
> I know where I think the "natural resonance" lies for a VOEvent  
> packet (whether XML or anything else), and it certainly isn't a  
> "point [before] which relational or more explicitly hierarchical  
> techniques are required" - which is to say a flat table of three  
> columns: name, utype, value.
>
> For one thing, omitting all these technology options from  
> discussion, the packet does "want" to have a basic structure similar  
> to <Who>, <What>, <Where> + <When>, <How>, <Why> and a citations  
> mechanism.  It does not want to have utypes from a half dozen data  
> models mixed up together in one pair of {} braces like enzymes in a  
> cell membrane.
>
> Many VOEvent packets represent a measurement of some sort.  The  
> independent variables - suitable for targeting follow-up  
> observations - go in <WhereWhen>, whether STC or something else.   
> The dependent variables - clues at the scene of the crime - go in  
> <What>.  This latter corresponds most closely to what has been  
> referred to as a payload - data, perhaps referencing an external  
> data model via utypes.
>
> On the other hand, if the nature of a data model is something that  
> "has to be understood by a human or (human conceived) code", isn't  
> the proof of the concept precisely STC?  STC is the most  
> "astronomical" of IVOA data models (astronomical as opposed to  
> astrophysical).  Those of us with an astronomy background (may) grok  
> the need for such a thing.  Those with a computer science  
> background, (perhaps) not so much.  Where is the balance point for  
> STC in the schema/utype tug of war?  This discussion has focused on  
> <What>.  Is it rather <WhereWhen> we should be debating?
>
> Rob