VOTable agenda Current VOTable status News from Applications Referring STC (as a data model example) Relations between s Questions about VOTable schema.

VOTable agenda Current VOTable status News from Applications Referring STC (as a data model example) Relations between s Questions about VOTable schema Late topics Actions & Future

Where are we ? VOTable1.1 is almost 3 years old (quite stable!) quite generally used, many tools What’s missing:  general referencing to external data models, especially STC  Final schema which satisfies the applications... and some (bogus?) tools

News from Applications VOConvert v1.0 (successor of ConVOT) VOStat (beta version) (on Friday) VOMegaPlot (many rows, density plots), VOPlot v1.4 TOPCAT v2.3 (supports all formats: TABLEDATA / FITS / BINARY). Problem of GROUP not solved ?

Referencing Models in VOTable The tabular material may contain in its fields (columns) any kind of data it is impossible to add into a VOTable document all the various XML codes related to all data models developed by the VO a VOTable document therefore refers to data models without including them

Utypes: what is it ? in VOTable schema: utype is a non-mandatory attribute of any RESOURCE TABLE FIELD PARAM GROUP  originally created for DAL needs  is an acceptable attribute wherever the ucd accepted  contrary to the ucd, gives a fully detailed meaning of the field, parameter or group ucd = broad semantics, typically used for data mining utype = detailed semantics, refers to a data model

Utype: its usage in VOTable can supply an exact description of the column contents immediate application for referencing quantities (parameters and/or fields) which exact meaning is crucial  systems of coordinates: celestial, terrestrial, solar,... (connection with STC)  time definitions (connection with STC)  photometric systems & filters  more generally any parameter part of a model, simulation...

STC Connection STC is an essential component to precise the conventions of dates, locations, coordinate systems (WhenWhere in VOEvent) used in most VO components should replace (and deprecate) the COOSYS ad-hoc convention

Scenarios for STC 5 scenarios are proposed on an example of a table having 5 columns: ObservingTime, RightAscension, Declination, ErrorRA, ErrorDec examples proposed on the VOTable forum. Very few answers up to now – but we have to take a decision this week !

----------------------------------------------------------------- ObservingTime RightAscension Declination RA_Err Dec_Err (ICRS, deg) (ICRS, deg) (arcsec) (arcsec) ----------------------------------------------------------------- 2007-05-13T23:00:05 358.1234 +05.1234 0.19 0.19 2007-05-13T23:00:06 358.4567 -05.4321 0.21 0.22 2007-05-13T23:00:07 358.5678 +04.1234 0.23 0.22 2007-05-13T23:00:08 358.6789 -04.4321 0.22 0.25 ----------------------------------------------------------------- A very simple example

<PARAM name="CooFrame" datatype="char" arraysize="*" utype="stc:AstroCoordSystem.SpaceFrame.CoordRefFrame.Type" value="ICRS" /> <PARAM name="CooFrameOrigin" datatype="char" arraysize="*" utype="stc:AstroCoordSystem.SpaceFrame.ReferencePosition.Type" value="TOPOCENTER" /> <PARAM name="CooType" datatype="char" arraysize="*" utype="stc:AstroCoordSystem.SpaceFrame.CoordFlavor.Type" value="SPHERICAL" /> Double referencing

<FIELD ID="OT" name="ObservingTime" datatype="char" arraysize="19" utype="stc:AstroCoords.Time.TimeInstant.ISOTime" ucd="time.start;obs.exposure" /> <FIELD ID="RA" name="Right Ascension" datatype="double" utype="stc:AstroCoords.Position2D.Value.C1" ref="ICRS_TOPO_SPH" unit="deg" ucd="pos.eq.ra" /> <FIELD ID="DEC" name="DEClination" datatype="double" utype="stc:AstroCoords.Position2D.Value.C2" ref="ICRS_TOPO_SPH" unit="deg" ucd="pos.eq.dec" /> <FIELD ID= "Err1" name="RA_Error" datatype="float" utype="stc:AstroCoords.Position2D.Error.Value.C1" ref="ICRS_TOPO_SPH" unit="arcsec" ucd="error;pos.eq.ra" /> <FIELD ID= "Err2" name="DEC_Error" datatype="float" utype="stc:AstroCoords.Position2D.Error.Value.C2" ref="ICRS_TOPO_SPH" unit="arcsec" ucd=”error;pos.eq.dec" /> Default UTC Time

<PARAM name="TimeScale" datatype="char" arraysize="*" utype="stc:AstroCoordSystem.TimeFrame.TimeScale" value="TT" /> <PARAM name="TimePos" datatype="char" arraysize="*" utype="stc:AstroCoordSystem.TimeFrame.ReferencePosition.Type" value="TOPOCENTER" /> <PARAM name="CooFrame" datatype="char" arraysize="*" utype="stc:AstroCoordSystem.SpaceFrame.CoordRefFrame.Type" value="ICRS" /> <PARAM name="CooFrameOrigin" datatype="char" arraysize="*" utype="stc:AstroCoordSystem.SpaceFrame.ReferencePosition.Type" value="TOPOCENTER" /> <PARAM name="CooType" datatype="char" arraysize="*" utype="stc:AstroCoordSystem.SpaceFrame.CoordFlavor.Type" value="SPHERICAL" /> Time defined No double referencing

<PARAM name="TimeScale" datatype="char" arraysize="*" utype="stc:AstroCoordSystem.TimeFrame.TimeScale" value="TT" /> <PARAM name="TimePos" datatype="char" arraysize="*" utype="stc:AstroCoordSystem.TimeFrame.TOPOCENTER" value="" /> <PARAM name="CooFrame" datatype="char" arraysize="*" utype="stc:AstroCoordSystem.SpaceFrame.ICRS" value="" /> <PARAM name="CooFrameOrigin" datatype="char" arraysize="*" utype="stc:AstroCoordSystem.SpaceFrame.TOPOCENTER" value="" /> <GROUP name="CooType" datatype="char" arraysize="*" utype="stc:AstroCoordSystem.SpaceFrame.SPHERICAL" > <PARAM utype="stc:AstroCoordSystem.SpaceFrame.SPHERICAL.coord_naxes" value="2" /> <PARAM name="SpectralPos" datatype="char" arraysize="*" utype="stc:AstroCoordSystem.SpectralFrame.TOPOCENTER" value="" />

<PARAM name="STC_ID" datatype="char" arraysize="*" utype="stc:AstroCoordSystem.id" value="TT_ICRS_TOPO"/> <PARAM name="TimeScale" datatype="char" arraysize="*" utype="stc:AstroCoordSystem.TimeFrame.TimeScale" value="TT" /> <PARAM name="TimePos" datatype="char" arraysize="*" utype="stc:AstroCoordSystem.TimeFrame.ReferencePosition.Type" value="TOPOCENTER" /> <PARAM name="CooFrame" datatype="char" arraysize="*" utype="stc:AstroCoordSystem.SpaceFrame.CoordRefFrame.Type" value="ICRS" /> <PARAM name="CooFrameOrigin" datatype="char" arraysize="*" utype="stc:AstroCoordSystem.SpaceFrame.ReferencePosition.Type" value="TOPOCENTER" /> <PARAM name="CooType" datatype="char" arraysize="*" utype="stc:AstroCoordSystem.SpaceFrame.CoordFlavor.Type" value="SPHERICAL" /> <PARAM name="AstroCoo" datatype="char" arraysize="*" utype="stc:AstroCoords.coord_sys_id" value="TT_ICRS_TOPO"/> duplication of the meaning of TT_ICRS _TOPO

<PARAM name="STC_ID" datatype="char" arraysize="*" utype="stc:AstroCoordSystem.id" value="TT_ICRS_TOPO"/> <PARAM name="TimeScale" datatype="char" arraysize="*" utype="stc:AstroCoordSystem.TimeFrame.TimeScale" value="TT" /> <PARAM name="TimePos" datatype="char" arraysize="*" utype="stc:AstroCoordSystem.TimeFrame.ReferencePosition.Type" value="TOPOCENTER" /> <PARAM name="CooFrame" datatype="char" arraysize="*" utype="stc:AstroCoordSystem.SpaceFrame.CoordRefFrame.Type" value="ICRS" /> <PARAM name="CooFrameOrigin" datatype="char" arraysize="*" utype="stc:AstroCoordSystem.SpaceFrame.ReferencePosition.Type" value="TOPOCENTER" /> <PARAM name="CooType" datatype="char" arraysize="*" utype="stc:AstroCoordSystem.SpaceFrame.CoordFlavor.Type" value="SPHERICAL" />

<PARAM name="AstroCoo" datatype="char" arraysize="*" utype="stc:AstroCoords.coord_sys_id" value="TT_ICRS_TOPO"/> Double referencing

…conclusion ? definition of AstroCoordSystem – necessary or just reference some component of STClib (not yet fully described in STC) ? Wouldn't it be better to have distinct references for time and coordinates ? (most frequently time specification is completely disconnected from coordinate system) double referencing (from GROUP and from FIELD) – useful or bad ? GROUP hierarchy – can it be problematic ?

Why not choose Simplicity? AstroCoordSystem definition only for non- standard system – use otherwise a reference if agreed with other groups, have separate Space, time, wavelength, etc... axes “double referencing” optional

Relations between tables (1) One VOTable document may contain several tables, meaning tables logically grouped. In the relational model, relations between tables are specified via the concept of keys basic key definitions: primary key (non-null, unique) and foreign key (must exist as primary in the related table) A simple solution: GROUPs

Relations between tables (2)...

Relations between tables (3)...

Relations between tables (4) Other possible interesting details: order of the data, e.g. with

Relations between tables (5) What is better:  just a with a specific name ?  prefer the definition of some “relational” data model and refer to these groups with utypes ?

ref attribute to TABLE (1) Current definition: A TABLE may have a ref attribute referencing the ID of another table previously described, which is interpreted as defining a table having a structure identical to the one referenced: this facility avoids a repetition of the definition of tables which may be present many times in a VOTable document.

ref attribute to TABLE (2) the ref attribute refers to the table structure, what about the following: 1 2 1.1 2.1

ref attribute to TABLE (3) from Moscow meeting: allow a reference to an empty table only (i.e. a table without part) is useful for many chunks of the same data structure (e.g. excerpts around a set of positions)  but would it better to allow several in a ?  prefer a supplementary column ?

VOTable schema changes (1) Problem of code generators (xsd) where the class generated by TABLEDATA consists of TD [][] instead of a class TR [] where TR consists in TD []  Easy to solve if an attribute is added to, e.g.  discussed in Moscow – strong opposition !  could be in the schema without being allowed

VOTable schema changes (2) problem – again a bug from code generator  has just 3 attributes: name value ID, plus simple content (i.e. any non-tagged text between and ). This content generates a conflict with the “value” attribute  would be wise to make similar to where datatype is a string (character string of any length), which means: accept utype ucd ID ref unit attributes accept sub- elements

VOTable schema changes (3) Streaming processing delivering VOTable output: there must be a possibility of providing a diagnostic about possible failure in the output stream allow to insert and tags after a ?

VOTable schema changes (4) discussed in Moscow: RESOURCE recursivity can be a problem, accept ? Deprecate, replaced by with its parameters and utypes to the STC model. Accept several in a ?  VOTable1.2 : volunteers to test the new schema ?

VOTable document changes Write down how to reference the STC with actual examples Explain the table relations (primary / foreign key conventions) with examples; other conventions ? Detail the null/NaN conventions

VOTable agenda Current VOTable status News from Applications Referring STC (as a data model example) Relations between s Questions about VOTable schema.

Similar presentations

Presentation on theme: "VOTable agenda Current VOTable status News from Applications Referring STC (as a data model example) Relations between s Questions about VOTable schema."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

VOTable agenda Current VOTable status News from Applications Referring STC (as a data model example) Relations between s Questions about VOTable schema.

Similar presentations

Presentation on theme: "VOTable agenda Current VOTable status News from Applications Referring STC (as a data model example) Relations between s Questions about VOTable schema."— Presentation transcript:

Similar presentations

About project

Feedback