comments

[Tony Linde]

Some comments on the latest version of the IVOA SkyNode Interface (apologies
for cross-posting but there are registry issues in this).

First comment is really about the scope of the document. I think it really
encompasses three or four separate areas that ought to be addressed each in
its own recommendation:

1. Section 4 refers to a 'Standard VO Interface', ie the minimum interface
that *any* service must meet to be registered on the VO. (I guess this
document would fit into the DAL stream of IVOA?)

2. The sections 5 & 6, ADQL and SkyQL, ought to be a single document under
the VOQL stream: SkyQL can be subsumed under the ADQL document as the string
representation of an ADQL query. I think the ability to accept a SkyQL
string ought to be optional for a skynode, while ADQL is mandatory: xml is
much easier to decode than straight text. Any portal which allows the user
to enter text queries ought to translate it to ADQL before submitting to a
skynode.

3. Section 8, SkyNode Interface, ought to specify the minimum interface that
*any* sky service must meet to be registered on the VO. 
Note: the new resource schema devised by Ray and me refers to a SkyService,
but I'd be happy to accept SkyNode as a name (much more catchy :) )

4. There are references in the document to query functions: REGION and
XMATCH. We should think about whether these should each be addressed by
simple single recommendations or all included in the ADQL one. (Also part of
the VOQL stream.)

5. Section 7, SkyQuery Portal: this is certainly separate from the above two
concepts but I don't think it really needs to be an IVOA standard. It will
be up to individual projects how they construct portals for users.


More general comments on the content of the document:

A. ADQL needs some means of identifying both column names and UCDs, along
the lines of my example at
http://www.ivoa.net/twiki/bin/view/IVOA/TonyOnUCDs#Example_query . See the
rest of that document for the reason why.

B. I find the explanation of the different levels very confusing. I assume
that you're trying to identify how complex a query that a given skynode can
handle. Is it wise to second guess which combination of functions a service
will choose to implement? Maybe we need some way to identify the functions
offered: a list of namespace defined enumerated list of functions (so some
functions coould be namespaced from the VOQL recommendation above, others
namespaced for that specific service).

C. I like the idea of using, in the short term, the ShortName as the unique
identifier of mirrored datasets, but see also my idea for a more complex
Relationship type in http://ivoa.net/forum/registry/0440.htm .

D. re QI-19: I don't see any benefit to adding the need to accept SQL-92
queries as well as ADQL ones. This might be an option which some skynodes
offer but it should not be mandatory. It is enough for each skynode to
translate ADQL into its own query language without also having to do so for
SkyQL and ADQL.


I'm impressed with the amount of work that has gone into this document and
hope my comments help.

Cheers,
Tony. 

__
Tony Linde                       Phone:  +44 (0)116 223 1292
AstroGrid Project Manager        Fax:    +44 (0)116 252 3311
Dept of Physics & Astronomy      Mobile: +44 (0)7753 603356
University of Leicester          Email:  ael at star.le.ac.uk
Leicester, UK   LE1 7RH          Web:    http://www.astrogrid.org