VOTable Meetings: Conclusions VOTable 1: Monday 24 May VOTable 2: Thursday 27 May

VOTable sessions 2 sessions: VOTable1 on Monday – towards an approved version for VOTable1.1 discussions of last adjustments VOTable2 on Thursday -- actual usage and perspectives many applications available (App. Int. Group) Hierarchy in tables columns and VOList

VOTable1.1 GROUP Content Change: GROUP be constructed ONLY from FIELDref, PARAMref, and PARAM, and may not be constructed from FIELD directly. Motivations: keep the "flat" table structure a parser not aware of GROUPs can find the FIELDs without examining the element hierarchy.

VOTable1.1: UCDs mandatory ? Question: Should it be mandatory for all Fields and Params to have UCDs? (no) automated translation from ascii becomes impossible (yes) smart systems can interoperate more effectively Resolved: UCD is not mandatory

VOTable1.1 and UCD-1+ Action: correct the use of old UCD in the VOTable specification to reflect the UCD1+. Accept also UCD in TABLE

VOTable1.1 and utype utype is designed to link the tabular format to key pieces of an external data model. can be an attribute of most elements: FIELD, PARAM, GROUP, TABLE and RESOURCE. NOTE: what about FIELDref and PARAMref? No obvious consensus – utype attribute could be added if it is a help for the DM connection.

Other (minor) VOTable1.1 changes DEFINITIONS marked as "deprecated". Addition of an optional nrows attribute GLU links marked as "href=glu://..." rather than gref=http://... Include the XSD as part of the VOTable document Indicate some "bad pratices" in the document rather than changing the XSD to enforce some domain definition rules

VOTable1.1 Status & Roadmap Slightly modified version of VOTable1.1 for beginning of June, ask for final comments, to get it as an IVOA recommendation ASAP Verification in several tools that the XML Schema of VOTable1.1 is fully operational, with proper reference to IVOA radix.

VOTable Session 2: Applications The AIG lists > 15 applications or libraries showing the VO standards in action --- and VOTable is present in all of them 4 applications presented: STIL / TOPCAT (D. Giaretta) supports all 3 VOTable serializations + other tabular formats X-match tool in Aladin (Th. Boch) VOTable in WebServices (T. Budavari) VOPlot in interaction with Aladin (A. Khembavi)

VOTable Session 2: Remarks The applications demonstrate the usefulness of a generic table model for interoperability of data moving around Impacts of changes in VOTable on applications becomes significant (1 week for SkyQuery to move from VOTable1.0 to VOTable1.1)

VOTable Session 2: Relations to other VO data models The STC model (A. Rots) as a possible replacement for the COOSYS element – not that obvious to integrate in VOTable (discussed also in the DM group) Obvious links between the FIELD structure and DM's basicQuantity or Registry's VOResource

VOTable Session 2: New Proposals Tables within table cells (P. Osuna) the feeling is that a classical join would achieve the same purpose VOList as a cousin to VOTable (G. Rixon) table is a set of objects with identical structure; VOList would be a set of schema instances Need to find use cases to demonstrate the usefulness of the concept

Thanks to those who contributed! Meeting more efficient than a succession of mail bursts on the VOTable mailing list ! No input from other VO group leaders about necessary VOTable changes we assume that VOTable fulfills its role !