action items

[Matthew Graham]

Hi Roy,

On Sep 23, 2009, at 3:25 PM, Roy Williams wrote:

> Your talk from Hotwired summarizes the SEAP as of April 2008.
> http://www.cacr.caltech.edu/hotwired2/program/presentations/SEAP.pdf
> Some of my comments attached.
>
> (1) It says: "a FIELD with the ucd “meta.ref.url” containing the  
> location from which the full VOEvent packet corresponding to that  
> record of the table may be retrieved."
> Question: How can I put in the SEAP response another URL that shows  
> more? For example
> http://www.skyalert.org/event/xml/9997/ goes to the XML for the  
> original event, but
> http://www.skyalert.org/events/6148/ is much richer with the whole  
> portfolio

What is a portfolio? VOEvent is a standard format and so users know  
what they are getting. Richer data structures are a great idea but if  
I hit an unfamiliar SEAP service and I get back a data format that I  
do not know then that is not a lot of use to me. In the specification  
itself (and not my talk), the language is also very clear that this  
what MUST be returned but that "there may be other FIELDs in the  
table. Their specification should include a description, datatype and  
UCD." So you can put in other links if you wish but you need to put in  
the links to VOEvents first and foremost.

> (2) The event IVORN carries multiple meanings. The general form is  
> ivo://authorityID/resourceKey#local_ID. We are using the first part  
> to define the event stream and the second for a local identifier of  
> the event. This we will need to search on the "preIVORN" (the part  
> before the #). To get all evenbts from the Fermi observatory, we  
> want preIVORN=ivo://nasa.gsfc.gcn/Fermi.

Agreed, and this ties in with our ideas about registering VOEvent  
streams in the registry. I will add this functionality to the  
specification.

> (3) Searching on authorIVORN may not be much help if the author did  
> not use that element. As it says in the VOEvent spec, "As an  
> alternative to quoting Author information over and over, this  
> information can be published to the VO registry, then referenced  
> through an IVORN. The <AuthorIVORN> element contains the identifier  
> of the organization responsible for making the VOEvent available."

I'm not sure what the point here is - can you please elaborate? Do you  
want this search term removed?

> (4) Params can be in Groups. This is not handled in the current  
> version of the spec.

Agreed - would the following be acceptable:

In VOEvent packets, Params are often arranged in (named) Groups. The  
name used in a parameter search can therefore be qualified by the  
Group name (as a prefix and using a '.' as a separator between the  
Group name and the Param name) if the search is for a specific  
parameter within a specific Group. For example

seap.param =  Ast1.mag1

would look for a Param called 'mag1' within a group called 'Ast1'.  
Matching just on a Group name can be achieved by omitting any Param  
name but keeping the separator, thus:

seap.param = Ast1.

If there is no separator then it is assumed that this a search on a  
Param name (default behaviour).

> (5) What can be done about searching on string parameters? Strict  
> equality? Contains? Startswith, Endswith?

The current behaviour is strict equality and case sensitivity (so  
seap.param = Ast1 matches 'Ast1' but not 'ast1'). We could broaden  
this to include something akin to the '%' in SQL queries, e.g.

seap.param = %st%

which would meet your contains, startswith and endswith. Anything more  
than this, though, should go in the CEAP (Complex Event Access  
Protocol).

> (6) I am assuming that a "dataType" attribute will appear in the  
> VOEvent2.0 spec, so that we know whether something is a number or a  
> string. For strings "19" < "2" but for floats 19 > 2.

The current version of SEAP is based around VOEvent 1.1. I would  
anticipate a SEAP 2.0 to deal with queries against the VOEvent 2.0  
data model.

> (7) If there are multiple constraints, are they combined with AND or  
> OR?

Multiple constraints are applied in conjunction (AND) as is consistent  
with IVOA (and the WWW) practice.

> (8) I think that the Units of a param should be left well alone. A  
> SEAP implementation should know that 2 < 19, but should not know  
> that 2 kilometers > 19 meters.

Searching on units is just meant for string matching and nothing more.  
So I want to find all radio transients where the peak flux is greater  
than some value and this has been measured in Jy (as reported in the  
VOEvent). Nowhere in my query string do I specify what units my  
fiducial value is in so the SEAP implementation is not doing unit  
conversion.

> (9) Some in the VOEvent community would like to build special schema  
> for things like orbital elements and tables. Once the What section  
> has these complex data types beyond numbers and strings, how will  
> SEAP constraints act on these?

This is the beyond the scope of the current SEAP spec. These schema  
will be part of VOEvent 2.0? In which case, this will be covered by  
SEAP 2.0.

> (10) Is KML a mandatory output format?

No, the specification says: "The service may respond with a XML  
document in the KML format".

> (11) The last page of your presentation with the complex search  
> regions seems much too complex. I vote to support cone search only:
> seap.pos.ra = 120 & seap.pos.dec = 15 & seap.pos.size = 0.5

The syntax of the positional search allows for these type of searches  
and these have been requested by the community (at Hotwiring 1). This  
is also consistent with the other IVOA access protocols.

> (12) Which VOTable is being used? Remember the 1.2 will not be  
> compatible with earlier versions.

The libraries that handle VOTable can deal with all official versions.  
Since the version of the VOTable is declared in the namespace at the  
top of the document, this is not an issue. However, for practical  
reasons, we should specify a particular version to be used by  
implementors. Does anyone have a preference?

	Cheers,

	Matthew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/voevent/attachments/20090925/95026c7e/attachment-0001.html>