action items

[Roy Williams]

Matthew
Thank you for all your work on this. Some responses below.
Roy

>> 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.
What I want is to put in other columns that have URLs, and label them 
with meta.ref.url, but not to be confused with the "special" column that 
links to the original XML. How about using "meta.ref.url:meta.main" for 
the column of links to the XML?
>> (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.

OK
>> (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?

The search term is fine, its just that it is not sufficient to find all 
the events from a particular author. You will need to search both the 
AuthorIVORN and the contactName etc.

>> (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).

Looks fine. We should check also on character sets -- what is allowed in 
a Param name or Group name, which of those need to be escaped to be part 
of a GET query.


>> (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.

In answer to both (5) and (6), the problem with VOEvent 1.1 is that all 
parameters are strings, because there is no dataType attribute in the 
Param definition. So if the values of two parameters are "2" and "19", 
we cannot tell if they should be converted to floats (2 < 19) or not 
("2" > "19").

>> (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.

OK
>> (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.

OK
>> (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.

OK. But before we extend the data model of VOEvent to include more 
complex things that Params and Groups, let us think of its effect on the 
SEAP. "Find all events which have an ephemeris that predicts dec>45 
three weeks from now".

>> (10) Is KML a mandatory output format?
>
> No, the specification says: "The service may respond with a XML 
> document in the KML format".

OK. I would also suggest including a simpler format such as IPAC tables 
or even CSV.

>> (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.

OK.

>> (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?

My preference is for VOTable 1.2 to be backward compatible with VOTable 
1.1, which would essentially make this whole question moot.

Roy

-- 

California Institute of Technology
626 395 3670