action items
Matthew Graham
mjg at cacr.caltech.edu
Fri Sep 25 17:24:11 PDT 2009
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>
More information about the voevent
mailing list