Minutes of VOQL-TEG Meeting #4

VOQL-TEG Meeting #4

Date: 08-Mar-2007
Time: 14:00 (UTC)

Present: BG,DT,FO,IO,KA,PO(partially)
Absent: AS,PD,YS
Meeting conducted by IO
Minutes by: A. Stebe

0) Approval of previous meeting minutes

Minutes approved.

1. Actions list review

/+VOQL-TEG-1/AI#7 on FO (plus DT/KA): to propose a mechanism for
getting//
table metadata within the TAP and possible output format.
/Action closed. Various inputs were sent. Agreements and open issues
discussed during the meeting. See below.

/+VOQL-TEG-1/AI#9 on PO/DT: to start writing the TAP document.
/Still open.

/+VOQL-TEG-2/AI#1 on ALL: to send to the list real code examples of
how//
we deal with REGION constructs _and_ special constructs (like the CROSS *APPLY) *
/Action still open. Inputs from KA and PD. IO comments during meeting
that ESAVO approach is similar to AstroGrid. Waiting for more inputs.

/+VOQL-TEG-2/AI#2 on AS/FO: to initiate the writing of an IVOA
standard//
document for the description if a Service that addresses the Crossmatch issue.
/Still open.

/+VOQL-TEG-2/AI#3 on ALL: to give ideas on the name to give to the//
aforementioned Service (describing crossmatch issues).
/Still open.

2) General discussion

TAP Metadata format :
KA argues that the metadata info must be accessible from the service and
in the same format as used in the Registry VOResource XSD. Whether returning the full VOResource or just the table metadata fragment is not
an issue. Argued that the Registry XSD is incomplete for TAP usage, and could/should be extended in coordination with the Registry WG. DT presents an alternative solution using VOTable. The usage would not be similar to SIAP v1.0, but rather return metadata info in the data part of the VOTable, as if it (or even exactly like it) was queried and extracted from a DB table. The major advantage of this solution is that clients must support VOTable for data output anyway, so they can use the
same libraries. KA argues that clients support the VOResource schema also anyway (to call the Registry), and that DT's solution makes for two
different formats for this metadata in the VO. Conclusion : two possibilities. VOTable serialisation or VOResource fragment. Discussion to follow on the list. Agreement from all : metadata must be accessible from the service directly.

TAP Metadata query :
Two clear solutions, simple TAP specific methods or full query language (ADQL) as in SQL92.
Agreement from all : specific methods much simpler (a few methods with minimal param input). Query language is overkill.

Review of comments from Jeff Lusted on ADQL doc : Very useful comments. Details and typos will be fixed in the next update
of the doc.
General agreement on the basic points of Jeff comments. More detailed comments are good inputs for latter doc finalisation. IO argues that the deprecated ADQL/x schema should not drive the current
writing of the document.
New ADQL structures in the doc (absent from ADQL/x) should be reviewed to filter unnecessary or superfluous ones. PO proposes to put Jeff as co-author of the ADQL specification doc. Region constructs for the query language still need to be submitted from
all.

**

*3) AOB
*

Possible face to face discussions with people present at the Spectroscopy Workshop held in Madrid (21-23 March). Eventual telecon with missing people.
**

List of personal acronyms:

AS:     Alex Szalay
BG:     Benjamin Gufler
DT:     Doug Tody
FO:     Francois Ochsenbein
IO:     Inaki Ortiz
KA:     Kona Andrews
PD:     Pat Dowler
PO:     Pedro Osuna     
YS:     Yuji Shirasaki

-- 
Pedro Osuna Alcalaya

European Space Agency (ESA)
European Space Astronomy Centre (ESAC)
Research and Scientific Support Department (RSSD)
Astronomy Science Operations Division (SCI-SD)
e-mail: Pedro.Osuna-at-esa.int
Tel + 34 91 813 13 14    Fax: +34 91 813 11 72
-------------------------------------------------                                                                                
European Space Astronomy Centre (ESAC)
P.O. Box 50727
E-28080 Villafranca del Castillo
MADRID - SPAIN


================================================================================================
This message and any attachments are intended for the use of the addressee or addressees only. The
unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content
is prohibited. If you received this message in error, please delete it from your system and notify
the sender. E-mails can be altered and their integrity cannot be guaranteed. ESA shall not be liable
for any e-mail if modified.
=================================================================================================