VOEvent used for solar knowledge base

[Rob Seaman]

On Jul 18, 2007, at 1:35 AM, Frederic V. Hessman wrote:

>> The original notion was to embed <References> to external RTML  
>> documents.  The above seems reasonable usage, however, and if so,  
>> we would likely also want to permit embedded RTML.  I would like  
>> to initially entertain the idea that such imported schema would be  
>> limited to specific elements, not written across the entire  
>> packet.  That is, STC would be restricted to <WhereWhen> and lmsal  
>> and rtml would be restricted to <How>.  Comments?
>
> Yet another good example of why the RTML schema should permit RTML  
> snippets rather than forcing a root RTML element?   The RTML 3.2  
> was changed to stop this kind of flexibility (for purely software  
> rather than scientific reasons).

I'd certainly think there would be any number of reason for embedding  
RTML fragments within other documents - including possibly  
recursively within RTML itself.  In any event, this is independent of  
VOEvent, which could, for instance, rely on a hacked RMTL or LMSAL  
schema with the root restriction removed.  The same would apply if  
VOEvent fragments were to be embedded in external documents, although  
in that case I would think we would just grab the definition of <Why>  
or whatever and include it directly in the other schema.  Chaining  
(if not recursion) within VOEvent is handled via citations, of course.

In any of these cases, the usual tools like XSLT can then encapsulate  
the fragments back into complete documents of whatever type to pass  
through subsequent applications.

> I include a "simple" SOHO-EIT RTML document which covers the  
> corresponding content so that most of this <How> becomes unnecessary.

I think this is a separate conversation between you and Elizabeth.  I  
don't think the context of Elizabeth's message was looking for  
alternatives to the LMSAL schema for these packets, but it's great if  
RTML is general enough to support this usage.  Different communities  
outside the traditional RTML bailiwick will likely already have their  
own instrument control/observation definition schema, that could most  
simply just be accepted as is.  (I'd be deeply skeptical about  
permitting alternatives to STC, however.)  The nature of the <How>  
element is to require some level of application specific expertise to  
use productively, in any case.  The common scaffolding of VOEvent  
packet handling rests largely with the other elements.

> Also, multi-telescope spacecraft may be better described using the  
> following construct (also not yet kosher):
>
> 	<Device type="spacecraft">
> 		<Telescope name="EIT">
> 			...
> 		</Telescope>
> 	</Device>

The ground-based equivalent in NOAO's data model would be "site".  An  
observatory has multiple sites, a site has multiple telescopes, a  
telescope has multiple instruments, etc.  Instruments are often  
shared between telescopes, so could be matrixed in a different way,  
but since the precise behavior of the instrument often changes due to  
f-ratio, etc., it is just as reasonable to regard Mosaic-I @ Mayall  
(4m) as distinct from Mosaic-I @ WIYN-0.9m.  Of course, with modern  
block scheduling a telescope is typically shared between multiple  
institutions, too.  WIYN is in effect a time-share telescope between  
its partners, all the way down to the copyright of resulting data.   
And sites often host resources from multiple observatories.  It's all  
very incestuous.

> The current proto-proposal for an appropriate "Standard Vocabulary"  
> description fits easily and would be
>
> 	ucd="phys.magneticField;morphology.loop"

Cool.

- Rob