VOEvent used for solar knowledge base

Rob Seaman seaman at noao.edu
Tue Jul 17 15:32:50 PDT 2007


Hi Elizabeth,

> I'd like to highlight a new solar use case for the VOEvent schema.
> Lockheed Martin is building a heliophysics features and event  
> knowledge
> base (http://www.lmsal.com/helio-informatics/hpkb/). The  
> knowledgebase is
> built up as solar events are identified, described  as VOEvent packets
> with the addition of <lmsal:*> tags, and submitted to the  
> knowledgebase.

As some of us discussed a few weeks back, this seems like a very cool  
application that we are eager to support.  I don't believe the  
standard has to evolve to permit these packets (once we iron out some  
issues), just the schema.

> The VOEvent schema already imports the IVOA's STC schema - can  
> additional
> schemas be imported as well so that VOEvent packets can include  
> customized
> elements like the <lmsal:*> tags while still conforming to the  
> VOEvent schema?

I personally think this is a good idea.  Do you have a revised  
VOEvent schema for the working group to consider?

> I've attached a sample XML file (describing a coronal loop)  
> generated by
> the SolarSoft vobs/ontology module's struct4export and export_event
> procedures. You may notice a <Group> placed inside <WhereWhen> that
> describes the loop's placement on the Sun. The Lockheed group is  
> amenable
> to moving such groups to <What>.

I think this would be preferred.  <WhereWhen> has enough work to do  
with STC.  BTW, I'm pleased to see an example of solar STC usage,  
demonstrating the versatility of the IVOA space-time model.

Additional comments are interspersed with the sample XML.

Rob
------

> <?xml version="1.0" encoding="UTF-8" ?>
> <voe:VOEvent ivorn="Reserved for KB archivist: KB entry identifier"  
> role="observation" version="1.1" xmlns:voe="http://www.ivoa.net/xml/ 
> VOEvent/v1.1" xmlns:lmsal="http://sot.lmsal.com/solarb/"  
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
> xsi:schemaLocation="http://www.ivoa.net/xml/VOEvent/v1.1 http:// 
> www.ivoa.net/xml/VOEvent/VOEvent-v1.1.xsd">

I'll leave precision pedantry to others, but you would want to  
namespace STC, too - either here or in <WhereWhen>.

I presume actual IVORNs would be used.  Have you considered how the  
knowledgebase would interact with IVOA registries?

>     <Who>
>        <!-- Data pertaining to curation -->
>        <Name>Reserved for KB archivist: KB entry made by</Name>
>        <AuthorIVORN>Reserved for KB archivist: URL to suppl. info.</ 
> AuthorIVORN>
>        <Date>2007/6/19 3:26:24</Date>
>     </Who>

The <Date> should be ISO-8601 per the standard (http://ivoa.net/ 
Documents/latest/VOEvent.html).

>     <What>
>        <!-- Data about what was measured/observed. -->
>        <Group name="Loop_required">
>            <Param name="EVENT_NPIXELS" value="59"/>
>            <Param name="EVENT_PIXELUNIT" value="0.5 arcseconds"/>
>        </Group>
>     </What>

Reasonable usage.  You might want to consider the distinction between  
the name of a group and its type.  "Loop_required" sounds like a type  
to me.  I'm a bit bemused by the question of appropriate "PIXELUNIT"  
usage.  A <Param> can have a unit as well as a ucd (and maybe a utype  
in the future).  Not sure what the best expression is here.

Comments are ok, but you might consider whether these would better be  
expressed as <Descriptions> - probably not for these simple examples,  
but such annotations are appropriate for users as well as programmers.

>     <WhereWhen>
>         <!-- Data pertaining to when and where something occured -->
>         <ObservationLocation id="EIT">
>             <AstroCoords coord_system_id="UTC-HPC-TOPO">
>                 <Time>
>                      
> <TimeInterval>1999-07-19T13:48:10.092,1999-07-19T13:48:23.596</ 
> TimeInterval>
>                 </Time>
>
>                 <Position2D unit="arcsec">
>                        <Value2>
>                            <C1>460.000</C1>
>                            <C2>955.000</C2>
>                        </Value2>
>                        <Error2>
>                            <C1>-1.00000</C1>
>                            <C2>-1.00000</C2>
>                        </Error2>
>                 </Position2D>
>                 <SpatialRegion>
>                     <Region>Box</Region>
>                     <!-- Coordinates of lower-left corner of  
> bounding box -->
>                     <Value2>
>                          <C1>451.000</C1>
>                          <C2>939.000</C2>
>                     </Value2>
>                     <!-- Coordinates of upper-right corner of  
> bounding box -->
>                     <Value2>
>                          <C1>460.000</C1>
>                          <C2>955.000</C2>
>                     </Value2>
>                 </SpatialRegion>
>             </AstroCoords>
>         </ObservationLocation>

Since you didn't namespace STC, I suspect this won't actually validate.

>        <Group name="Loop_required">
>            <Param name="CHAINCODETYPE" value="unknown"/>
>            <Param name="SKEL_CHAINCODE" value="unknown"/>
>            <Param name="SKEL_CURVATURE" value="-1.00000"/>
>            <Param name="SKEL_NSTEPS" value="-1"/>
>            <Param name="SKEL_STARTC1" value="-1.00000"/>
>            <Param name="SKEL_STARTC2" value="-1.00000"/>
>        </Group>
>     </WhereWhen>

Perhaps you can explain in more detail why this might be more  
appropriate for <WhereWhen>, rather than for <What>.  If there is no  
strong justification, please relocate to the <What> element.

>     <How>
>        <!-- Data pertaining to how the feature/event detection was  
> performed -->
>        <lmsal:data>
>            <lmsal:OBS_ChannelID>EIT 195</lmsal:OBS_ChannelID>
>            <lmsal:OBS_Instrument>EIT</lmsal:OBS_Instrument>
>            <lmsal:OBS_MeanWavel>195.000</lmsal:OBS_MeanWavel>
>            <lmsal:OBS_WavelUnit>Angstroms</lmsal:OBS_WavelUnit>
>        </lmsal:data>
>        <lmsal:method>
>            <lmsal:FRM_Contact>ms2 at mssl.ucl.ac.uk</lmsal:FRM_Contact>
>            <lmsal:FRM_DateRun>2007/6/19 3:26:24</lmsal:FRM_DateRun>
>            <lmsal:FRM_HumanFlag>no</lmsal:FRM_HumanFlag>
>            <lmsal:FRM_Identifier>Mike Smith</lmsal:FRM_Identifier>
>            <lmsal:FRM_Institute>MSSL</lmsal:FRM_Institute>
>            <lmsal:FRM_Name>LoopRecog</lmsal:FRM_Name>
>            <lmsal:FRM_ParamSet>inputFile, sigma,  
> minimumContourPoints, OutputFile</lmsal:FRM_ParamSet>
>        </lmsal:method>
>     </How>

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?

>     <Why>
>        <Inference probability="Inf"/>
>        <Concept>Loop</Concept>
>        <lmsal:EVENT_TYPE>LP: Loop</lmsal:EVENT_TYPE>
>     </Why>

I think better yet would be for the lmsal event types to inform the  
evolution of native VO vocabulary lists, such as a VOEvent UCD  
namespace.  Perhaps Rick can comment.

The value of the probability attribute should be a floating point  
number bounded between 0.0 and 1.0.

>     <Reference name="FRM_URL" uri="http://www.mssl.ucl.ac.uk/twiki/ 
> bin/view/SDO/CoronalLoopDeployment"/>

You might include a meaningful <Description> corresponding to this  
<Reference>.

> </voe:VOEvent>

The name "knowledgebase" implies interesting interdependencies  
between the packets contained within.  I'm wondering if the VOEvent  
<Citations> element could be particularly useful for this purpose.




More information about the voevent mailing list