Summary of Agreements and Open Issues

From: Maria A. Nieto-Santisteban <nieto-at-skysrv.pha.jhu.edu>
Date: Wed, 31 May 2006 21:18:54 -0400 (EDT)

Dear all,

In the text below, we have tried to summarize the agreements and open issues discussed in Victoria (and Madrid).

Please let us know about any missing points

Thanks

Yuji & Maria

---

Agreed in Madrid:

1 - Define ADQL CORE and ADQL Full
2 - TOP belongs to ADQL Core
3 - OFFSET is an extension
4 - Data types follow VOTable datatypes
5 - Archive qualifiers use the Resource Identifier (service maps SHORTNAME 

and Identifier)
6 - Use " " (instead of []) to enclose special identifiers

Agreed in Victoria:

7 - Tables must be always aliased
8 - Rename ADQL Full to ADQL Extended
9 - Remove the Unit syntax from the ADQL grammar
10 - Support 2 types of time data types (instead of 17):
	2006-05-16T10:30:50.012
	and 
	Julian Date

11 - REGION


	* Keep the REGION constraint in ADQL Core

	* Keep the frame explicit in the REGION constraint

	* Keep the REGION syntax as it is currently defined 

		eg: REGION('CIRCLE J2000 200.0 5.0 1.0')
	  instead of something like 
		POINT(t.ra1, t.dec1) IN REGION('CIRCLE J2000 200.0 5.0 1.0')
		OR
		REGION('CIRCLE J2000 t.ra1 t.dec1 200.0 5.0 1.0')
	
	  Bottom line is: Data provider chooses what columns are used to 
resolve a REGION query
	  -- This might be revised later, but for ADQL 1.0 , specially for 
the CORE, we felt was unnecesary complexity	


	* Circle default radius changes from arcminutes to degrees

12 - Keep Select Into 'VOSPACE:Location' syntax as it is instead of "CREATE TABLE AS ..."

• CREATE adds a new grammar element which was considered unnecessary for the moment

13 - VOTable (briefly discussed during the VOQL session,

     further discussed and resolved in a small meeting) 


	* Use <GROUP> to include column metadata

e.g.

<FIELD datatype="double" ID="col1" name="t.ra" unit="deg" ucd="pos.eq.ra;meta.main"/>
<FIELD datatype="double" ID="col2" name="t.dec" unit="deg" ucd="pos.eq.dec;meta.main"/>

<GROUP name="Coordinate">
   <FIELDref ref="col1"/>
   <FIELDref ref="col2"/>

   <PARAM name="frame" datatype="char" arraysize="*" value="FK5"> </GROUP>

• When a column is aliased, use <FIELD name = "column_alias"... />
• When a column is an expression, use <FIELD name = "expression"... />

Under discussion

---

0 - We have two ways of representing the ADQL Core BNF:

• What BNF works better for you?

http://www.ivoa.net/internal/IVOA/InterOpMay2006VOQL/ADQL-20060516-CoreApendix.pdf

or

http://www.ivoa.net/internal/IVOA/InterOpMay2006VOQL/ADQL-20060508-withComments.doc (in the apendix)

1 - What is a SkyNode? Does SkyNode belong to VOQL or DAL?

Current definition:

"Astronomical data (e.g., catalogs) may be published as SkyNodes. ... SkyNodes provide the front-end to the actual databases, using the interface described in this document." (This document refers to the SkyNode Specification)

Is now the moment to rename/redefine what a SkyNode is or should be?

2 - ADQL/s - ADQL/x. Which should be mandatory to be supported?

• Some people believe there is no need for ADQL/s and VOQL should care only for the definition of ADQL/x. Clients take care of composing ADQL/x queries.
• Some people believe (SkyNode) services should support a method that allows for direct ADQL/s. It is more likely that a SkyNode knows how to parse and translate ADQL/s than a general client knows how to build the ADQL/x.

3 - Should the XMATCH syntax be part of ADQL? Is XMATCH a user defined function? More in
http://www.ivoa.net/internal/IVOA/InterOpMay2006VOQL/SummaryofVOQL-specialSesion.pdf

4 - Should be XMATCH renamed?

XMATCH has rich astronomical meaning. Astronomers think of XMATCH not only as a positional match but rather as the process of identifying that two or more objects correspond to one.

5 - XMATCH distance

• what is the syntax?
  1. XMATCH_Distance (s, t, k, distance)
  2. XMATCH_DISTANCE(t1.ra, t1.dec, t2.ra, t2.dec, d) AND XMATCH_DISTANCE(t1.ra, t1.dec, t3.ra, t3.dec, d)
• what is the behaviour and output? a.1) The two node case is "simple" XMATCH_Distance (s, t, distance) returns pairs (s,t) within distance a.2) n > 2 ? What does it mean XMATCH_Distance (s, t, k, distance)? What does it mean XMATCH_Distance (s, t, !k, distance)? b) True/False - what does this mean? How does this work?

6 - XMATCH chi2

• what is the syntax? a.1) XMATCH_Chi2 (s,t,k, threshold) a.2) XMATCH_Chi2 (s,t,!k, threshold)
• what is the behavior and output? a.1) objects (positional match only) which are in s, t and k within a threshold. XMATCH_Chi2 returns the best guess for the position. a.2) By Adding the '!' operator in front of the node we are requesting for objects that appear in s and t but not in k. Of course, there is the issue of whether an object is not found because it has not be detected or because the region has not been observed. To addressed the second one we need to work with footprints which will help us to figure out how two, or more catalogs overlap.

7 - Where should XMATCH go?
FROM | WHERE SELECT s.ra, s.dec, t.ra, t.dec, x.d, x.ra, x.dec FROM SDSS:PhotoPrimary s, TWOMASS:PhotoPrimary t WHERE XMATCH(s,t, 3)

• This syntax implies using 'x' as a default qualifier.
• Right now there is no way to refer to the XMATH results in the SELECT (e.g best guess for position or chi2)
• XMATCH is a constraint and makes sense to put it in the WHERE statement OR

SELECT s.ra, s.dec, t.ra, t.dec, x.d, x.ra, x.dec FROM SDSS:PhotoPrimary s, TWOMASS:PhotoPrimary t,

            XMATCH(s,t, 3) x  

• This syntax uses an explicit qualifier
• XMATCH is a "FUZZY JOIN" and makes sense to put it in the FROM statement
• This looks closer to SQL

Is worth while to change the syntax?

8 - Is necessary the keyword #upload in the language? 9 - Do we need comments?
10 - ADQL was case insensitive. Do we really want to deal with case sensitive queries?
11 - Does the new Capability registry schema solve the issue of adding new types of SkyNodes? Received on 2006-06-01Z03:19:43